geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Problems running grails applications on Geronimo 2.1
Date Wed, 02 Nov 2011 20:19:18 GMT
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 <hsn@sendmail.cz>

>
>   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

Mime
View raw message