[jboss-as7-dev] Fwd: [Lift] Re: java.lang.VerifyError using Lift-2.5-M4 with Scala-2.10

Galder Zamarreño galder at redhat.com
Wed Feb 20 03:25:08 EST 2013


One of the many reasons why I love JBoss AS7 :))

Begin forwarded message:

> From: Galder Zamarreño <galder at zamarreno.com>
> Subject: Re: [Lift] Re: java.lang.VerifyError using Lift-2.5-M4 with Scala-2.10
> Date: February 20, 2013 9:14:36 AM GMT+01:00
> To: liftweb at googlegroups.com
> Reply-To: liftweb at googlegroups.com
> 
> Those using Escalante will find that there's no need for any classloading workaround (or black magic) to solve the commons-codec issue.
> 
> The problem I was facing was a simple user error where I was adding two different versions of commons-codec to the WAR file (again, transitive dependencies stabbing me in the back...)
> 
> But, what it's nice about Escalante is that deployments work totally separate of the jars the server uses. In fact, JBoss Application Server 7 that sits beneath Escalante uses commons-codec 1.4 for some of its internal components, but this dependency never leaks into the deployments unless you force it through. So, by default, you'll never find server jars leaking into deployments.
> 
> So, if you wanna avoid classloading nightmares, I'd highly recommend that you deploy Lift apps on Escalante :)
> 
> On Saturday, 16 February 2013 20:14:26 UTC+1, Peter Petersson wrote:
> On 02/16/2013 05:09 PM, Richard Dallaway wrote:
>> Thank you Peter.  The inverted class-loader is the behaviour I'd expect for a servlet container. Is it now more a question of why it ever worked, rather than why it doesn't work with 2.10? :-)
> 
> Yea you could say that. 
> The reason I did not tested with inverse-classloading from the beginning was that it did not make sense for the app to end up in a vastly different class loading scenario just because it was compiled with a different version of Scala (this is still a bit fuzzy)     
> 
> Inverse classloading should be avoided in a production environment as it affects all classes but it is a nice tool to have for finding out stuff like this :). 
> 
> The best workaround (and a acceptable one) for the problem is to use the following in the geronimo deployment plan. 
> 
> <sys:import-package> !org.apache.commons.codec*</sys:import-package>
> Note: This is the preferred replacement of the older hidden-classes filter stuff
> 
> It will filter out the containers common codec so that the app will get hold of its own codec jar (in the war /lib/)
> Lift is currently using commons codec v1.6 in all builds.
> 
> I have found two uses of common codec (v1.3) in the geronomo container  
> * In the enterprise service bus stuff provided by the ServiceMix component 
> * In Apache Felix Preferences Service (OSGI stuff, org.apache.felix.prefs-1.0.4.jar)
> 
> The late is core stuff in Geronimo so that is probably the one interfering with the Scala 2.10 build 
> 
> best regards 
>   Peter Petersson
>  
> 
>> Richard
>> 
>> 1 https://cwiki.apache.org/GMOxDOC22/classloading.html
>> 
>> On 16 February 2013 11:56, Peter Petersson <peterss... at gmail.com> wrote:
>> 
>> As you can see on the Geronimo list i have found a work around for Geronimo deployment. 
>> However the solution I use may not be optimal in all situations so I hope someone in the Geronimo community will take a closer look.
>> 
>> The way I resolved the deploy/start problem with the 2.10 build was to add the inverse-classloading [1] setting to geronimo's deployment descriptor.
>> 
>> [1] http://geronimo.apache.org/schemas-3.0/docs/geronimo-module-1.2.xsd.html#h1508775248
>> 
>> best regards 
>>   Peter Petersson
>> 
>>  
>> 
>> On 02/16/2013 12:48 PM, Richard Dallaway wrote:
>>> Thanks for this - I'm currently trying to get some traction on the issue for Geronimo. I'm hoping what we find for that will help with this.
>>> 
>>> Richard
>>> 
>>> On 14 February 2013 09:28, Galder Zamarreño <gal... at zamarreno.com> wrote:
>>> Richard,
>>> 
>>> I was able to replicate the issue with this repo:
>>> https://github.com/galderz/escalante/tree/t_rearch
>>> 
>>> To reproduce:
>>> 
>>> 1. Change Scala version in https://github.com/galderz/escalante/blob/t_rearch/pom.xml to 2.10
>>> 2. Do: mvn clean install -pl build
>>> 3. Either from IDE or command line, run this Arquillian test: https://github.com/galderz/escalante/blob/t_rearch/modules/lift/src/it/testsuite/src/test/scala/io/escalante/test/lift/helloworld/HelloWorldTest.scala
>>> 
>>> NOTE: Test uses embedded Escalante instance, so give it some hefty VM options and add correct log manager, i.e.
>>> 
>>> -Xmx512m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.jboss.logmanager.LogManager
>>> 
>>> Cheers,
>>> 
>>> 
>>> On Wednesday, 13 February 2013 12:05:39 UTC+1, Richard Dallaway wrote:
>>> Thank you. My simple (non-Lift) app deploys OK under both those versions.  I've also just tried the M4 lift_blank template and that deployed and ran OK under Tomcat 7.0.28 with Scala 2.10 under JDK 1.7. 
>>> 
>>> If you can get a github repo together that reproduces the problem, I'm happy to take a look.  Just let me know.
>>> 
>>> Richard 
>>> 
>>> On 13 February 2013 09:59, Andreas Joseph Krogh <and... at officenet.no> wrote:
>>> På onsdag 13. februar 2013 kl. 10:45:42, skrev Richard Dallaway <ric... at dallaway.com>:
>>> Thanks for that -- which Tomcat is that?
>>>  
>>> I notice Geronimo use 7.0.27 but I've been using 7.0.35
>>>  
>>> My standalone Tomcat is 7.0.28 and the tomcat7-maven-plugin-2.0 uses Tomcat-7.0.30
>>>  
>>> --
>>> Andreas Joseph Krogh <and... at officenet.no>      mob: +47 909 56 963
>>> 
>>> Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
>>> Public key: http://home.officenet.no/~andreak/public_key.asc
>>>  
>>> -- 
>>> -- 
>>> Lift, the simply functional web framework: http://liftweb.net
>>> Code: http://github.com/lift
>>> Discussion: http://groups.google.com/group/liftweb
>>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>>  
>>> --- 
>>> You received this message because you are subscribed to the Google Groups "Lift" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u... at googlegroups.com.
>>> 
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>> 
>>> -- 
>>> -- 
>>> Lift, the simply functional web framework: http://liftweb.net
>>> Code: http://github.com/lift
>>> Discussion: http://groups.google.com/group/liftweb
>>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>>  
>>> --- 
>>> You received this message because you are subscribed to the Google Groups "Lift" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u... at googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>> 
>>> -- 
>>> -- 
>>> Lift, the simply functional web framework: http://liftweb.net
>>> Code: http://github.com/lift
>>> Discussion: http://groups.google.com/group/liftweb
>>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>>  
>>> --- 
>>> You received this message because you are subscribed to the Google Groups "Lift" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u... at googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>> 
>> -- 
>> -- 
>> Lift, the simply functional web framework: http://liftweb.net
>> Code: http://github.com/lift
>> Discussion: http://groups.google.com/group/liftweb
>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups "Lift" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u... at googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>> 
>> -- 
>> -- 
>> Lift, the simply functional web framework: http://liftweb.net
>> Code: http://github.com/lift
>> Discussion: http://groups.google.com/group/liftweb
>> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups "Lift" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+u... at googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
> 
> 
> -- 
> -- 
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
>  
> --- 
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to liftweb+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20130220/4b798b7f/attachment-0001.html 


More information about the jboss-as7-dev mailing list