I'm attempting to test against the latest Glassfish app server (V2 b41, a.k.a. Beta 2) and there seems to be an issue with wicket that didn't arise when I had tested it in earlier versions of Glassfish (and I've never encountered in JBoss). Nothing else in the app is causing any problems.
I built an "enterprise" app in Netbeans 5.5.1, using Java EE 5 as the target platform and Glassfish V2 Beta 2 as the app server. I'm trying to (once again) move our storefront application to Glassfish, which was built using Wicket 1.2.x and JPA/EJB3 and currently runs on JBoss 4.0.5. On my local dev box, everything seems to work as expected. I can build, deploy, and run the app. On the staging box I've installed Glassfish exactly like I did locally and can deploy the application, and it runs. However, if I restart the app server, when the app comes back up I'm unable to pull it up, I get the following exception:
[code]
com.myapp.abcommerce.ui.admin.UserSession cannot be cast to com.myapp.abcommerce.ui.admin.UserSession at com.myapp.abcommerce.ui.panel.HeaderPanel.(HeaderPanel.java:38) at com.myapp.abcommerce.ui.ProductCatalog.(ProductCatalog.java:57) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58) at wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:267) at wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:286) at wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:205) at wicket.request.compound.DefaultEventProcessorStrategy.processEvents(DefaultEventProcessorStrategy.java:65) at wicket.request.compound.AbstractCompoundRequestCycleProcessor.processEvents(AbstractCompoundRequestCycleProcessor.java:57) at wicket.RequestCycle.doProcessEventsAndRespond(RequestCycle.java:896) at wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:929) at wicket.RequestCycle.step(RequestCycle.java:1010) at wicket.RequestCycle.steps(RequestCycle.java:1084) at wicket.RequestCycle.request(RequestCycle.java:454) at wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:219) at javax.servlet.http.HttpServlet.service(HttpServlet.java:705) at javax.servlet.http.HttpServlet.service(HttpServlet.java:818) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:258) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:189) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:611) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:564) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:81) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:193) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:611) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:558) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1067) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:611) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:558) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1067) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:255) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:549) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199) at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:345) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252) at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:93)
[/code]
If I then re-deploy the application - it magically runs again and there is no ClassCastException. This line is exceptionally amusing to me:
"com.myapp.abcommerce.ui.admin.UserSession cannot be cast to com.myapp.abcommerce.ui.admin.UserSession"
...oh REALLY now?
I'll post the UserSession class, if I must, but it's worked in production on JBoss 4.0.x for over a year now so I'm skeptical that there's any problems w/ it - it hasn't changed in that time either.
Are there any known issues w/ Glassfish at this time? Is Glassfish the culprit here, entirely? I posted this on the Wicket mailing-list as well, just to see what comes up.
Thanks!
[Message sent by forum member 'zambizzi' (zambizzi)]
http://forums.java.net/jive/thread.jspa?messageID=216366