I created a Play framework v1.2.5 web service and I've successfully deployed it as a WAR file on Tomcat 7.0.30. It's been working fine for months.
I recently tweaked the code a tiny bit (I literally added trim() to 2 functions). Tested it. It works. I generated a new WAR but it consistently fails to start on the server.
The catalina logs say: geronimo-servlet_2.5_spec-1.2.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
but I tried removing the jar as previous posts suggest but it's still not working. Others have suggested it is a memory problem. I asked my sysAdmin to increase the memory but he hasn't done it yet.
Am I on the right track or is there another solution?
Solved it! I noticed that the Tomcat 7 server was using an older version of Java.
I had my sys admin upgrade to JDK 1.7x and the darn WAR started working again. That still doesn't explain why it stopped working in the first place.
And yes, the Play 1.2.5 documentation says it only works on tomcat 6x but my company won't roll back to 6.
Related
i've deployed birt.war on my tomcat 7.0.41. Used manager app to verify that the war file was deployed correctly. if i click on birt path, i get HTTP status 404 - /birt/ error. it says the requested resource is not available. i've stoped and restarted the server multiple times.
Can you help?
TIA,
Thomas
I am answering my own question. New to BIRT. Downloaded the latest one - 4.8. After googling a bit, found out that 4.5 is compatible with tomcat 7. I was able to deploy and run a sample report.
I had a repository with code that I was testing via running a server at localhost. The standard procedure was to start Apache-Tomcat-7, re-build the project using Maven and deploy it.
After a while of coding I decided to git stash current changes, then built and deployed the old version, it ran correctly in all browsers. After that I called git stash applyand once again built and deployed the created .war file. However, despite the correct version of code both in generated war and in the deployed .war, now none of the browsers see the new applied version.
I tried Ctrl+F5, removing cached files, shutting down Tomcat & deleting the logs & starting it again. And yet the changes, despite being correctly deployed, don't appear in browsers when I navigate to localhost.
How to fix it, what am I doing wrong?
It's possible the web application with your new code built correctly but is not deploying due to an error in the web.xml, init() or classloaders.
Look for a pair of lines in the catalina.out file that looks like this:
INFO: Deploying web application archive /usr/local/tomcat/apache-tomcat-7.0.63/webapps/web-apps#uits#qr.war
INFO: Deployment of web application archive /usr/local/tomcat/apache-tomcat-7.0.63/webapps/web-apps#uits#qr.war has finished in 5,123 ms
If you see an error after the "Deploying" line and/or no "Deployment" line, that might explain the issue.
Running Eclipse Indigo, Tomcat 7 on Windows - running the web application on the ROOT context with eclipse wtp plugin I am getting this intermittent problem where eclipse cannot find the compiled JSP. It occurs when first accessing the JSP and cannot be resolved except by stopping the Tomcat server and cleaning the Work directory and the project directory. The compile version is there in the eclipse directory structure:
.metadata\.plugins\org.eclipse.wst.server.core\tmp0\work\Catalina\localhost\_\org\apache\jsp\WEB_002dINF\...
but it still produces this error.
After some research I found this related thread which seems to suggest the problem only occurs when the application is deployed on ROOT.
http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/208071
And a bug has been entered:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=334977
Has anyone had a similar issue to this and knows a solution?
Hi please try to configure value as per first screen shot and change location as per second screenshot and try if that works for you.
At the moment we use glassfish 3.1 as application server for our enterprise application. The application(s) are packed within an ear. The ear contains approximately
5 wars,
10 jars and
60 jars(ejb) .
The deployment of the ear takes more than 10 minutes. Is there any chance to tweak the deployment time of the application?
BTW: We splitted the ear already in smaller pieces. But in most cases we need the complete suite deployed.
If you are trying to reduce development time, there is two way for it for glassfish as much as I know.
First, you can deploy as a directory with asadmin deploydir. As a result of that you can change jsp files and method bodies, thanks to hot swap technology.
But the most elegant solution is using an alternative library in order to decrease the amount of deployments. There are a few alternative for this but you can use jrebel. It is quite stable. JRebel is used to reduce deployments and reloads class files on the fly by jvm its jvm agent. It has support for almost all well known frameworks.
You could be running into this:
http://java.net/jira/browse/GLASSFISH-17094
Download the latest GlassFish 3.1.2 build and see if it solves your problem:
http://dlc.sun.com.edgesuite.net/glassfish/3.1.2/promoted/glassfish-3.1.2-b23.zip
Update: GlassFish Server 3.1.2 has been released:
https://blogs.oracle.com/theaquarium/entry/glassfish_3_1_2_final
Hope this helps.
I am using RAD 7.0. My web application works with a jar(contains the backend code for our application) which undergoes frequent changes. But whenever I replace the jar in the WebInf/lib folder of the war and restart the server, it does not pick up the latest jar. It keeps referring to the previous jar. I have to undeploy, restart server several times to make the war pick up the latest jar. Has anyone come across this issue? Any pointers will be useful.
Many thanks,
RJ
Is your server configured with "Run with resources within the workspace"?
If so, switch to "Run with resources on the server" and see if this solves the problem.
I have had my share of RAD problems not picking up new code, especially on RAD 6.0 and 7.0; on RAD 7.5, IBM finally seemed to have a grip on these issues.
You can also do a server clean to force the temp and work dirs to be cleaned and the code to be republished. RAD 7 has a problems and if you can upgrade to 7.5 many get resolved in that version.