EDIT : I made changes since I think my question may be missing some technical details
The problem occurs in Struts 1.3.x and is described by the following :
When modify classes related to Struts (e.g ActionForm, Action, and/or any class I use with them) then I get ClassCastException when I test my modifications (Without restarting my webapp).
If I restart my webapp after making the same modifications then there is no exception and changes made are visible when testing.
This behaviour is said to be NORMAL because of the following reasons :
My web container (weblogic) is configured to reload servlet and classes if changes are made
I assume that a different ClassLoader is used when modifications are made to my classes. Which may causes ClassCastException.
Thus I have to restart webapp everytime I want to test my source modifications…
What I wanna know is what can I do (programming pattern ? best practice ?) to avoid this kind of ClassCastException or to avoid restarting webapp to view my changes ?
Here is the stack trace :
java.lang.ClassCastException: my.package.here.MyActionClassNameHere
at org.apache.struts.chain.commands.servlet.CreateAction.getAction(CreateAction.java:65)
at org.apache.struts.chain.commands.AbstractCreateAction.execute(AbstractCreateAction.java:91)
at org.apache.struts.chain.commands.ActionCommandBase.execute(ActionCommandBase.java:51)
at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191)
at org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:305)
at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:191)
at org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1914)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:463)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:821)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
I have seen JRebel about page. It may be a solution but I am not ready to use it for my purpose (which is some very simple test using struts 1.3.x).
I’ll continue to do some parallel tests to understand a little more about this exception…
By default Struts 1.3 (latest 1.3.x) put action classes in cache to optimize performance (restarting deployment purge the cache). That was the cause of the exception because my modified classes are loaded by a different classloader from the previous one which was in cache.
This exception occurs during the step of retrieving the action instance (which starts here in the stacktrace).
By default this version of Struts implements the chain of responsability pattern (using an xml configuration file chain-config.xml). Thus the request processor mentioned above delegates action instance retrieving (or instantiation) to a CreationAction implementation (which is showed here in the stactrace) :
Following are solutions to avoid ClassCastException when making changes and donnot want to restart deployment.
Solution 1 :
Extend CreateAction with a custom class and redefine its getAction() method
In getAction() : If the super.getAction().getClass() has not the same classloader than the new one then make it return a new instance by calling super.createAction()
(That means that I should know the qualified class name of my Action class when comparing using the == operator otherwise I should not compare and always load a new action class with createAction)
Use a custom chain-config.xml to specify to use the custom CreationAction instead of the default one
Solution 2 : Extend RequestProcessor with a custom class and use it instead of the default one (i.e update parameters in struts-config.xml)
I think doing these should only be done when in development stage (to save some testing time) and should be avoid when in production stage for performance (and security) reasons.
I couldn’t have free time to add more detailled example code, config files, etc… I’ll try to do it one day (somewhere else). But for sure I test these and it worked for my purpose 🙂