I have an application written with Struts2 and Spring for DI and I'm using Tomcat 6 as container. Assuming I have packaged the application as my-application.war after deployment on Tomcat I can access it through http://my-host/my-application.
When I delete the .war file, Tomcat's supposed to undeploy the application and according to here When I try the http://my-host/my-application I should get:
HTTP Status 404
but instead I get:
HTTP Status 503 - This application is not currently available
When I redeploy the application to same context path I get a weird exception:
Unable to instantiate Action, [ActionClass], defined for '' in
namespace '/' Failed to convert value of type [MyClass] to required type
[MyClass] for property 'myClass': no matching editors or conversion strategy
found
in which ActionClass has a property myClass of type MyClass which is injected by Spring and by default is a singleton. It's weird because type of both objects is the same. I suspect the application don't get undeployed completely in the first place cause when I restart Tomcat the scenario will be repeated. I would appreciate any help on finding the possible cause of this.
Well I think I found the answer. As I guessed the problem was with the improper undeployment.
It seems that deploying and undeploying an application without restarting the tomcat is a tricky business. When you deploy your application Tomcat classloader loads the classes in of the application and once they're loaded it seems they won't be unloaded with undeployment. And constantly deploying and undeploying an application will cause a serious memory leak. This case is specially true with singletons since the remained version of object in JVM doesn't match the newly deployed class. Hence the error I got above.
The safe path seems to be restarting Tomcat each time you redeploy any application.
Sources helped me find these information:
What makes hot deployment a "hard problem"?
Tomcat: hot deploying new jars
This post on CodeRanch
And some more sources found on Google
Related
I have a Spring MVC 4 application deployed in tomcat. It works fine. I have to clone this app to have several applications with same behaviour but different configurations: database instance and folders for file management. Each for different customers. When I deploy de original application to Linux Tomcat it works fine (https://hostname:8443/app1).
Then I change the db connection settings (database name, username, and folders to manage some generated files) and change the name of the artefact to customername. But when I get into the application, it shows the login page right, but when login into the app, I'm getting the following error:
Status HTTP 500 - Request processing failed; nested exception is org.apache.tiles.request.render.CannotRenderException: java.io.IOException: JSPException including path '/WEB-INF/layout/header.jsp'
javax.servlet.ServletException: File [/WEB-INF/layout/header.jsp] not found
when accessing to https://hostname:8443/customername, which it's part of tiles template. Files exist in the deployed application, It's able to reach the login page, so it seems to be resolved the tiles config, but I don't know why is not able to reach the jsp files. It's working fine in local windows without secure Tomcat (port 8080).
EDITED
If I change the name of customername.war to app1.war it's working fine. Anybody knows where the war file keep a reference to the base application app1? It seems that there a reference to app1 in somewhere that makes that If I change the application name (artifact id) it does not reference to customername path.
Seems that it's a context root issue. I have changed it in STS (Project > Properties > Web Project Settings > Context root), deployed on Tomcat but still not working. It's supposed that only with changing the war file name, the context root of the application should be updated, but it's not working.
Upgrading Tomcat from 8.0 to 8.5.5 solves the issue. I don't know why, but there's an issue in 8.0 because no way to force context root for an application, not context.xml application file neither other configuration.
Just upgrade to 8.5.5 and deploy applications without context issue.
BR
I have an application which is working fine on Websphere server (as war and Eclipse Project).
Direct deploy on Liberty through WAR is also working fine.
I was trying to deploy it on WAS Liberty through Eclipse project. There are no console errors but once the application loads, none of the following files are getting loaded in the web page: js, gif, css
Because of this the page is looking distorted and most of the functionality is lost.
Surprisingly there are some JSPs in the js folder and these are getting loaded, so looks like the folders are published properly. But for all the mentioned files (js etc), I get following error in the browser console: 500 (Internal Server Error) .
There are no errors and the server log is also clean.
My setup: WAS Liberty 8.5, RHEL 6.5. Eclipse Luna, WDT 8.5.5.2. Project having Eclipse structure, not maven.
I have tried both loose config and 'from workspace' settings
Edit1: I noticed that Spring beans are not getting initialized properly. Getting null pointer on applicationContext.getBean.
OK, found the problem.
As I guessed this was related to spring initialization, though the problem was more code related.
Due to wrong implementation of REST implementation, where the base path was set as root application path (“/”), rest API classes were getting instantiated on application load and were then making calls to code which was instantiating few Spring beans.
But at this point the Spring listeners had not fired, hence the appcontext was empty. Some of the base application object were getting initialized with empty beans and hence spring security context and related classes were failing to serve the application content properly. (Problem is spring related code is created by another team and we just get the jar, hence I am not even able to debug it properly, so I don't know where it was failing exactly)
The thing that makes it Liberty specific is: The same problematic code is working fine on Websphere full profile and Weblogic and even on Liberty if we deploy as WAR. Not sure what classloading difference is causing difference in behaviour.
Thanks to all who took time and efforts for replying.
I am facing the same issue using open liberty and Eclipse Krazo when the base path is
application path (“/”)
so i have changed the path as shown below
package io.openliberty.sample;
import javax.ws.rs.ApplicationPath;
import javax.ws.rs.core.Application;
#ApplicationPath("")
public class ConfigApplication extends Application {
}
Now the CSS and imgs are loading with no issues.
I have a web app running on Tomcat 6.0.35, which makes use of Spring 3.1.2, Hibernate 4.1.8 and MySQL Connector 5.1.21.
I have been trying to figure out what is causing Tomcat to keep running out of memory (Perm Gen) after a few redeploys.
Note: Don't tell me to increase Tomcat's JVM memory because that will simply postpone, the problem
Specifically, I made use of the VisualVM tool, and was able to eliminate some problems, including some mysql and google threads issues. I was also able to discover and fix a problem caused by using Velocity as a singleton in the web app, and also not closing at the correct time/place some thread local variables I was having. But I still am not completely able to eliminate/figure out this Hibernate issue.
Here is what I'm doing:
Deploy my webapp from my development IDE
Open a tomcat manager window in my browser
Start VisualVM and get the HeapDump on the tomcat instance
Go the tomcat manager and redeploy my webapp
Take another HeapDump in VisualVM
My first observation is that the WebappClassLoader for the original webapp is not garbage collected.
When I scrutinize the retained objects from the second HeapDump, the class org.hibernate.internal.SessionFactoryImpl features prominently which leads me to believe that it IS NOT being destroyed/closed by Spring or something along those lines (and hence the WebappClassLoader still having a reference to it).
Has anyone encountered this problem and identified the correct fix for it?
I don't currently have an idea what could be amiss in your setup but what I know is that using Plumbr you'll most likely find the actual leak(s).
the glassfish application server provides a nice monitoring REST interface.
To use it u can enable several monitorable items in the admin console, for example the EJB container. The documentation says, you can retreive EJB-statistics for every deployed application.
If you request a URL like localhost:4848/monitoring/domain1/server/applications/APPNAME/EJBNAME you will get statistics for a given EJB of the application.
Further, there is a possibility to look more deeply into each bean-method of the ejb, for example the executiontime, about which the documentation says:
"Time, in milliseconds, spent executing the method for the last successful/unsuccessful attempt to run the operation. This is collected for stateless and stateful session beans and entity beans if monitoring is enabled on the EJB container."
The problem now is, monitoring is enabled on the EJB-container (Level set to HIGH), but nothing is sampled in any bean-method in any EJB in any deployed application.
Is there something special to do in the bean and/or the glassfish ?
Thanks in advance for help,
Chris
EDIT:
Ok, I noticed something more about that behaviour:
In the server log you get a log message for each deployed EJB like that:
INFO: EJB5181:Portable JNDI names for EJB DataFetcher // ...
If I set the ejb-container monitoring level to HIGH (which is what I want to do), I get the following warning for each deployed EJB, regardless which app I deploy:
WARNING: MNTG0201:Flashlight listener registration failed for listener class : com.sun.ejb.monitoring.stats.StatelessSessionBeanStatsProvider , will retry later
I googled the warning but none of the resulst really help me enabling EJB monitoring...
This seems to be a Bug in Glassfish.
EJB Monitoring is currently not working in 3.1.2.
JIRA issue is already raised: http://java.net/jira/browse/GLASSFISH-19677
There is nothing "special" to do.
http://docs.oracle.com/cd/E18930_01/html/821-2431/abeea.html
For me it seems as if you probably enabled the monitoring option on the wrong configuration. Please double check.
To get rid of this message you can disable the monitoring on ejb container option below in the image
From Monitor Data--->Configure monitoring--->make ejb container log off
When i am running my application it give me this exception:-
Exception sending context initialized event to listener instance of class
org.springframework.web.util.Log4jConfigListener
java.lang.ExceptionInInitializerError
But this problem is not permanent. If i remove the log4j entries from web.xml and restart p.c and then again add log4j entries and start the server, then the application works fine.
I noticed that when the application is deployed and when i undeploy and again deploy the same application, this problem emerge.
Please help me ........ i am facing this problem from 3 months...
I just investigated it a little and have found the similar issue:
It causes when multiple jar file for log4j is available to application.
From web/application server and from build path(Included from other
path rather than web/application server)
You can see the entire thread here:
http://www.coderanch.com/t/551933/Spring/Exception-sending-context-initialized-event
looks like this is your problem.