OK, so could you attach the sample to the JIRA system? Or the one attached last time could reproduce this. Thanks.
2011/11/3 Radim Kolar <[email protected]> > > I partly agreed your opinions, the classloader is always a complex thing >> If the web applications ship the conflict libraries with the server >> runtime, there may be issues, and you could find almost all the application >> servers provide some classloading options to change the classloader >> behavior. Also, I am not sure why you say that the Geronimo classloading >> system is 'highly nonstandard', it will be better to have some detailed >> comments for it :-) >> > If you get this application - it runs everywhere with exception of > geronimo - websphere 7, jetty, tomcat, glassfish 3, weblogic 10.3. While > you can certainly tune classloading in every mentioned server, it is not > needed for majority of wars. In geronimo you need it for almost everything > which does not fall into hello world category. Non willingness to play with > custom deployement descriptors is reason why tomcat has so high market > share in J2EE world - people just put OpenEJB + Hibernate there and they > can make it run faster then in full J2EE stacks. > > > a. Not sure whether it is required to add javax.transaction in the >> filter option, usually, for those specification APIs, the ones from server >> side should always be used, as they are referenced by many server >> components. Anyway, if it makes your application work, that is fine. >> > thats exactly what that statement does. combined with inverse > classloading, it will make to ignore included JTA jar in grails application. > > b. From the stack trace, the CCE is thrown for the axiom package, it >> seems that spring-ws uses the saaj in its webservice processing, and by >> default, the axis2-saaj implementation is used in Geronimo runtime, and >> axis2-saaj is dependent on the axiom packages. I checked the spring-ws >> 1.5.0 packages, and found that axiom-1.2.5 is used, which is the same >> version with one from Geronimo 2.1 runtime. One possible solution is to >> removed the ones from your application packages. >> > grails springws plugin does not come with axiom and no axiom jar is found > in application jars. Springws plugin comes with this: > > 69 409 activation-1.1.1.jar > 1 651 965 bcprov-jdk14-1.43.jar > 6 461 com.russmiles.groovy.**webservices.client-1.0- > > 18 817 saaj-api-1.3.jar > 278 145 saaj-impl-1.3.2.jar (com.sun.xml.messaging.saaj) > 278 286 serializer-2.7.1.jar > 773 156 spring-security-core-2.0.4.jar > 776 014 spring-ws-1.5.8-all.jar > 23 346 stax-api-1.0.2.jar > 148 522 wsdl4j-1.6.1.jar > 323 799 wss4j-1.5.8.jar > 3 176 148 xalan-2.7.1.jar > 143 145 XmlSchema-1.4.3.jar > 447 633 xmlsec-1.4.3.jar > > i added axiom to list of filtered classes to make sure that version > packaged with geronimo is used but i got same error > > > <non-overridable-classes> > <filter>net.sf.cglib</filter> > <filter>javax.transaction</**filter> > <filter>javax.xml.soap</**filter> > <filter>org.apache.axiom</**filter> > </non-overridable-classes> > <inverse-classloading/> > > > >> If the application codes will interact with the server codes use those >> components, there may be still an issue there. >> > saaj support in geronimo might be wrong > -- Ivan
