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
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
On 16 February 2013 11:56, Peter
Petersson
<peterss...@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...@zamarreno.com>
wrote:
Richard,
I was able to replicate the issue with
this repo:
To reproduce:
2. Do: mvn clean install -pl build
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...@officenet.no>
wrote:
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
--
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...@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...@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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.