OK, so could you attach the sample to the JIRA system? Or the one attached last time could reproduce this.
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.
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 :-)
thats exactly what that statement does. combined with inverse classloading, it will make to ignore included JTA jar in grails application.
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.
grails springws plugin does not come with axiom and no axiom jar is found in application jars. Springws plugin comes with this:
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.
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<filter>javax.xml.soap</filter>
<inverse-classloading/>saaj support in geronimo might be wrong
If the application codes will interact with the server codes use those components, there may be still an issue there.