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
