Axis2 SAAJ implementation in Geronimo - possible class cast bug when unmarshalling?
I've hit trouble moving my JAXB-unmarshalled web service (based on Spring Web Services 1.0.0) from Tomcat 5.5.23 to Geronimo 2.0.1; stack trace below. I used JDK6 on Linux for both TC and Geronimo. I stripped the .war down to use dummy empty implementations of everything, with no extra jar's, so that only the unmarshalling was causing a problem. (I generate my JAXB classes with JDK wsimport on the command line and include them in WEB-INF/classes, so unlike for Axis2 and CXF they don't include Geronimo machinery-maybe this is a problem.) I think the problem is because of Geronimo's Axis 2 SAAJ implementation, and it can't be overridden even when classloader priority is configured to be to the servlet context. Also, I've tried setting JAVA_OPTS in the geronimo.sh startup script to include -Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.S OAPMessageFactory1_1Impl etc but it had no effect. My fix was to replace the impl and api jars in the Geronimo repository with empty files, so that the deployer's dependency checker was fooled and rmi and the server started without complaining. Now my web service works. But I have a bad feeling about what I've just done to Geronimo - probably it will prevent me using CXF in the same server. Anyone got a better workaround, or a fix for Geronimo? 16:33:04,183 WARN [SoapMessageDispatcher] Endpoint invocation resulted in exception - responding with SOAP Fault java.lang.ClassCastException: org.apache.axiom.soap.impl.dom.SOAPMessageImpl cannot be cast to org.apache.axiom.om.impl.dom.ElementImpl at org.apache.axis2.saaj.NodeImplEx.toSAAJNode2(NodeI mplEx.java:260) at org.apache.axis2.saaj.NodeImplEx.toSAAJNode(NodeIm plEx.java:181) at org.apache.axis2.saaj.SOAPElementImpl.getParentEle ment(SOAPElementImpl.java:723) at org.apache.axis2.saaj.SOAPElementImpl.getParentNod e(SOAPElementImpl.java:778) at com.sun.xml.bind.unmarshaller.DOMScanner.buildName spaceSupport(DOMScanner.java:159) at com.sun.xml.bind.unmarshaller.DOMScanner.buildName spaceSupport(DOMScanner.java:159) at com.sun.xml.bind.unmarshaller.DOMScanner.scan(DOMS canner.java:100) at com.sun.xml.bind.v2.runtime.unmarshaller.Unmarshal lerImpl.unmarshal0(UnmarshallerImpl.java:288) at com.sun.xml.bind.v2.runtime.unmarshaller.Unmarshal lerImpl.unmarshal(UnmarshallerImpl.java:271) at javax.xml.bind.helpers.AbstractUnmarshallerImpl.un marshal(AbstractUnmarshallerImpl.java:107) at org.springframework.oxm.jaxb.Jaxb2Marshaller.unmar shal(Jaxb2Marshaller.java:312) at org.springframework.ws.support.MarshallingUtils.un marshal(MarshallingUtils.java:54) at org.springframework.ws.server.endpoint.adapter.Mar shallingMethodEndpointAdapter.unmarshalRequest(Mar shallingMethodEndpointAdapter.java:145) at org.springframework.ws.server.endpoint.adapter.Mar shallingMethodEndpointAdapter.invokeInternal(Marsh allingMethodEndpointAdapter.java:135) at org.springframework.ws.server.endpoint.adapter.Abs tractMethodEndpointAdapter.invoke(AbstractMethodEn dpointAdapter.java:58) at org.springframework.ws.server.MessageDispatcher.di spatch(MessageDispatcher.java:211) at org.springframework.ws.server.MessageDispatcher.re ceive(MessageDispatcher.java:158) at org.springframework.ws.transport.support.WebServic eMessageReceiverObjectSupport.handleConnection(Web ServiceMessageReceiverObjectSupport.java:87) at org.springframework.ws.transport.http.WebServiceMe ssageReceiverHandlerAdapter.handle(WebServiceMessa geReceiverHandlerAdapter.java:57) at org.springframework.ws.transport.http.MessageDispa tcherServlet.doService(MessageDispatcherServlet.ja va:158) at org.springframework.web.servlet.FrameworkServlet.p rocessRequest(FrameworkServlet.java:475) at org.springframework.web.servlet.FrameworkServlet.d oPost(FrameworkServlet.java:440) at javax.servlet.http.HttpServlet.service(HttpServlet .java:713) at javax.servlet.http.HttpServlet.service(HttpServlet .java:806) at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:175) at org.apache.geronimo.tomcat.valve.DefaultSubjectVal ve.invoke(DefaultSubjectValve.java:56) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext. java:351) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAft erValve.invoke(GeronimoBeforeAfterValve.java:47) at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:104) at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:109) at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:563) at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:261) at
Geronimo 1.1.1 and Liferay 4, memory problems on startup and hot deployment
We have had trouble deploying Liferay 4.2.0 on Geronimo 1.1.1 out of the box with Liferay distro where they are prepacked together. I tried the 4.1.2 pro WAR file too and had the same memory problems. We immediately get PermGen memory use errors on Java 1.5.09 on RHEL 3, 4 and Windows XP even with more than 1 gig allocated. Sometimes it happens on startup, otherwise on the first hot deployment. Restarting after every deployment helps if the deployment didn't crash the server. On Tomcat 5.5, LR runs fine with little memory. The July 2006 archives contain discussion about blocking 1.1.1 because of this problem but it seems not to have happened. The user list contains a recent question, Liferay 4.2.0 and Geronimo 1.1.1 about the same problem on startup. And on JIRA there is issue GERONIMO-2644 that may be related:- Fix leaking ClassLoaders Created: 11/Dec/06 12:04 PM Updated: 11/Dec/06 12:19 PM Component/s: kernel Affects Version/s: 1.2 , 2.0-M1 Fix Version/s: 1.2 , 2.0-M1 Looks like we're leaking ClassLoaders. If you deploy/undeploy an app the ClassLoader(s) created for the app are not being GC'ed. Eventually, you'll run out of PermGen space. I assume that this is also causing the PermGen problems when running tests. Will this problem be fixed in 1.2 and if so, when is 1.2 release planned? We wanted to adopt Geronimo and go into production with it for running Liferay, but this is a killer for us. Thanks Paul.
RE: Geronimo 1.1.1 and Liferay 4, memory problems on startup and hot deployment
Bumping up MaxPermSize works great on 1.5. If Geronimo 1.1.1 is then stable for hot portlet deployment on LR4.2, we'll be able to use it. Thanks all round for the quick responses. Paul. -Message d'origine- De : Kevan Miller [mailto:[EMAIL PROTECTED] Envoyé : 20 December 2006 15:54 À : dev@geronimo.apache.org Objet : Re: Geronimo 1.1.1 and Liferay 4, memory problems on startup and hot deployment On Dec 20, 2006, at 8:46 AM, Jeff Genender wrote: Kevan M, Do you have any thoughts on the leaking classloaders? Hey Jeff, AFAIK, Geronimo 1.1.1 running on JRE 1.4.2 was clean. I ran Daytrader through multiple deploy/undeploy cycles. Daytrader is great, in this regard, because it hits a lot of our builder code... There are some temporal deploy/undeploy leaks, where a Thread Local variable will keep a classloader alive until the Thread is re-used by the system. This could cause issues when undeploying/deploying very large apps with lots of classes. I am seeing Classloaders being leaked in Geronimo 1.2-beta and 2.0- M1. It's looking like Java 1.5 is behaving differently than 1.4. So, it's possible that Geronimo 1.1.1 running on 1.5 has similar problems. I've been trying to get some time to look at these issues, but just have tenative data, at the moment... If PermGen problems are being encountered with a single app deployment, then you'll definitely need to bump up MaxPermSize, as you've suggested. FYI, The following option will cause the VM to print GC statistics (including PermGen info). -XX:+PrintGCDetails I have run Liferay 4.1.2 and 4.2 on Geronimo 1.1.1 setting the -Xms1G -Xmx1G and have never run into any memory problems what-so-ever, with the memory used at about 110M after it's up and running. I have run it on the Mac. Paul, Have you tried upping the permgen memory parameter on boot? Try adding this to JAVA_OPTS: -XX:MaxPermSize=128m Jeff Paul ANDERSON wrote: We have had trouble deploying Liferay 4.2.0 on Geronimo 1.1.1 out of the box with Liferay distro where they are prepacked together. I tried the 4.1.2 pro WAR file too and had the same memory problems. We immediately get PermGen memory use errors on Java 1.5.09 on RHEL 3, 4 and Windows XP even with more than 1 gig allocated. Sometimes it happens on startup, otherwise on the first hot deployment. Restarting after every deployment helps if the deployment didn't crash the server. On Tomcat 5.5, LR runs fine with little memory. The July 2006 archives contain discussion about blocking 1.1.1 because of this problem but it seems not to have happened. IIRC, all known memory-related issues got cleaned up for 1.1.1. However, I didn't run any tests on Java 5. So, it's possible that there may be some Java 5 issues for G 1.1.1, also... The user list contains a recent question, Liferay 4.2.0 and Geronimo 1.1.1 about the same problem on startup. I hadn't noticed this. Thanks for the pointer Paul. And on JIRA there is issue GERONIMO-2644 that may be related:- Fix leaking ClassLoaders Created: 11/Dec/06 12:04 PM Updated: 11/Dec/06 12:19 PM Component/s: kernel Affects Version/s: 1.2 , 2.0-M1 Fix Version/s: 1.2 , 2.0-M1 Looks like we're leaking ClassLoaders. If you deploy/undeploy an app the ClassLoader(s) created for the app are not being GC'ed. Eventually, you'll run out of PermGen space. I assume that this is also causing the PermGen problems when running tests. Will this problem be fixed in 1.2 and if so, when is 1.2 release planned? Well, IMO, this is a must-fix for a release (but just fine to have this problem in a beta/milestone). I don't know what kind of target Dain has for releasing 1.2. I certainly hope soon... We wanted to adopt Geronimo and go into production with it for running Liferay, but this is a killer for us. Paul, Well, let's get this problem cleaned up, then... ;-) I may ping you later with questions about how you're deploying Liferay, but will run some other tests, first... If you could gather some additional data using PrintGCDetails and open a Jira, that would be great. However, I should be able to make progress in the meantime... --kevan
