java.lang.VerifyError using Lift-2.5-M4 with Scala-2.10

[Andreas Joseph Krogh]

Hi Lifters.

 

When using Lift-2.5-M4 with Scala-2.10 I get this when booting my app:

 

Jan 26, 2013 11:18:51 AM org.apache.catalina.core.StandardContext filterStart
SEVERE: Exception starting filter LiftProxyFilter
java.lang.VerifyError: (class: net/liftweb/util/SecurityHelpers$class, method: md5 signature: (Lnet/liftweb/util/SecurityHelpers;Ljava/lang/String;)Ljava/lang/String;) Incompatible object argument for function call
        at net.liftweb.util.Helpers$.<init>(Helpers.scala:34)
        at net.liftweb.util.Helpers$.<clinit>(Helpers.scala)
        at net.liftweb.http.LiftRules.<init>(LiftRules.scala:165)
        at net.liftweb.http.LiftRules$.prodInstance$lzycompute(LiftRules.scala:77)
        at net.liftweb.http.LiftRules$.prodInstance(LiftRules.scala:77)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64)
        at net.liftweb.common.EmptyBox.openOr(Box.scala:644)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRules$.realInstance(LiftRules.scala:85)
        at net.liftweb.http.LiftRulesMocker$.toLiftRules(LiftRules.scala:49)
        at net.liftweb.http.provider.servlet.ServletFilterProvider$class.init(ServletFilterProvider.scala:38)
        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:922)

 

I start my VM with these arguments (with instrumentation using AspectJ-1.7.1):

 

/usr/lib/jvm/java-7-oracle/bin/java -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m -Xmx512m -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m -Xmx512m -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000 -javaagent:/home/andreak/.m2/repository/org/springframework/spring-instrument/3.2.1.RELEASE/spring-instrument-3.2.1.RELEASE.jar -classpath /home/andreak/programs/apache-maven-3.0/boot/plexus-classworlds-2.4.jar -Dclassworlds.conf=/home/andreak/programs/apache-maven-3.0/bin/m2.conf -Dmaven.home=/home/andreak/programs/apache-maven-3.0 org.codehaus.plexus.classworlds.launcher.Launcher tomcat7:run

 

Downgrading to Scala-2.9.2 using the exact same code/config works fine.

 

Anyone seen this, any hints?

 

Thanks.

 

--
Andreas Joseph Krogh <and...@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

[Diego Medina]

the only thing that comes to mind is, have you rebuilt (clean /
compile / package) when changing versions ?
Could you, as a test, compile your app in that server you are deploying it?

Hope that helps.

Diego

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



--
Diego Medina
Lift/Scala Developer
di...@fmpwizard.com
http://fmpwizard.telegr.am

[Andreas Joseph Krogh]

På lørdag 26. januar 2013 kl. 17:41:10, skrev Diego Medina <di...@fmpwizard.com>:

the only thing that comes to mind is, have you rebuilt (clean /
compile / package) when changing versions ?
Could you, as a test, compile your app in that server you are deploying it?

 

Yes, I've "mvn clean install"'ed my app when changin versions and made sure (using mvn dependency:tree) that I hav no version-conflicts or duplicate libraries haning around.

 

What do you mean by "compile the app in the server I am deploying it"?

[Diego Medina]

do you compile your war on your laptop and copy the war to your
server? if that;s what you do, how about compiling in the same server
as you deploy, for cases where you use a diff version of java on your
laptop (or desktop :) ), than on your server.

And I'm sure you already google about it, but I wonder if something
like this is useful
http://stackoverflow.com/questions/100107/reasons-of-getting-a-java-lang-verifyerror

Cheers,

Diego

[Andreas Joseph Krogh]

På lørdag 26. januar 2013 kl. 21:35:47, skrev Diego Medina <di...@fmpwizard.com>:

do you compile your war on your laptop and copy the war to your
server? if that;s what you do, how about compiling in the same server
as you deploy, for cases where you use a diff version of java on your
laptop (or desktop :) ), than on your server.

And I'm sure you already google about it, but I wonder if something
like this is useful
http://stackoverflow.com/questions/100107/reasons-of-getting-a-java-lang-verifyerror

 

I'm running the app using the same "mvn tomcat7:run" for both builds, no app-server, no deployment.

Yes, I've tried googling but haven't gotten any wiser yet...

[Diego Medina]

hm, the only think I would try next is to reduce the number of
dependencies to see which library is the issue. I think someone
reported a strange issue on 2.10 too, and they were using record, but
I didn;t see any followed up on that.

[David Whittaker]

I'd try it without the -javaagent flag.  See if disabling instrumentation lets you get past the filter startup, even if your app doesn't work correctly without it.

--

[Peter Petersson]

It was me reporting (problem on app server Geronimo with 2.1 build), I have not had time to follow up on the issue yet but I will get around to it and report back.

--from my cell
best regards Peter Petersson

[Galder Zamarreño]

I'm getting the same issue trying to deploy a basic HelloWorld app with Lift 2.5-M4 and Scala 2.10 on Escalante:

[0m [0m19:47:03,441 INFO  [io.escalante.lift.subsystem] (MSC service thread 1-5) Try to deploy: deployment "helloworld-default.war"

[0m [0m19:47:03,442 INFO  [io.escalante.lift.subsystem] (MSC service thread 1-5) Metadata is: LiftMetaData(Lift2x(2.5-M4),Scala(2.10.0),Buffer())

[0m [0m19:47:04,938 INFO  [org.jboss.as.arquillian] (MSC service thread 1-5) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."helloworld-default.war",unit=helloworld-default.war,tests=[io.escalante.test.lift.helloworld.HelloWorldTest]]

[0m [0m19:47:04,944 INFO  [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011006: OSGi Framework - 2.0.0.Final

[0m [0m19:47:04,971 INFO  [org.jboss.web] (MSC service thread 1-8) JBAS018210: Register web context: /helloworld-default

[0m [31m19:47:05,284 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/helloworld-default]] (MSC service thread 1-8) JBWEB000284: Exception starting filter LiftFilter: java.lang.VerifyError: (class: net/liftweb/util/SecurityHelpers$class, method: hash256 signature: (Lnet/liftweb/util/SecurityHelpers;Ljava/lang/String;)Ljava/lang/String;) Incompatible object argument for function call

at net.liftweb.util.Helpers$.<init>(Helpers.scala:34) [lift-util_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.util.Helpers$.<clinit>(Helpers.scala) [lift-util_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRules.<init>(LiftRules.scala:165) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRules$.prodInstance$lzycompute(LiftRules.scala:77) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRules$.prodInstance(LiftRules.scala:77) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.common.EmptyBox.openOr(Box.scala:644) [lift-common_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRules$.realInstance(LiftRules.scala:85) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftRulesMocker$.toLiftRules(LiftRules.scala:49) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.provider.servlet.ServletFilterProvider$class.init(ServletFilterProvider.scala:38) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.http.LiftFilter.init(LiftServlet.scala:922) [lift-webkit_2.10-2.5-M4.jar:2.5-M4]

at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:416) [jbossweb-7.2.0.Alpha2.jar:7.2.0.Alpha2]

at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3224) [jbossweb-7.2.0.Alpha2.jar:7.2.0.Alpha2]

at org.apache.catalina.core.StandardContext.start(StandardContext.java:3783) [jbossweb-7.2.0.Alpha2.jar:7.2.0.Alpha2]

at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:102) [jboss-as-web-7.x.incremental.546.jar:7.x.incremental.546]

at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_37]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_37]

at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_37]

I wonder if the issue might be related to the odd compile time dependencies that I spotted in my previous comment:

https://groups.google.com/forum/?fromgroups=#!topic/liftweb/ru3JEUc5pk0

Webkit for 2.5-M4 has a transitive dependency on Scala 2.10.RC3...

Maybe this is mixing up things...

Cheers,

[Galder Zamarreño]

This is very very odd.

Here's compile time dependencies I used to generate the app: https://gist.github.com/galderz/4717321 (all test cos I used ShrinkWrap to build the WAR file via test)

These are the jars contained in the WAR: https://gist.github.com/galderz/4717326 (FYI: scala-library comes from a JBoss module: https://gist.github.com/galderz/4717338)

Not sure if it has something to do here, but it's odd that both me and the user that reported this seem to be using Maven...

Any tips would be really handy at this point.

Or, ways to get around this issue, cos I'm really stuck right now.

Cheers,

[Andreas Joseph Krogh]

På tirsdag 05. februar 2013 kl. 19:53:46, skrev Galder Zamarreño <gal...@zamarreno.com>:

I'm getting the same issue trying to deploy a basic HelloWorld app with Lift 2.5-M4 and Scala 2.10 on Escalante:

 

[0m [0m19:47:03,441 INFO  [io.escalante.lift.subsystem] (MSC service thread 1-5) Try to deploy: deployment "helloworld-default.war"

[0m [0m19:47:03,442 INFO  [io.escalante.lift.subsystem] (MSC service thread 1-5) Metadata is: LiftMetaData(Lift2x(2.5-M4),Scala(2.10.0),Buffer())

[0m [0m19:47:04,938 INFO  [org.jboss.as.arquillian] (MSC service thread 1-5) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."helloworld-default.war",unit=helloworld-default.war,tests=[io.escalante.test.lift.helloworld.HelloWorldTest]]

[0m [0m19:47:04,944 INFO  [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011006: OSGi Framework - 2.0.0.Final

[0m [0m19:47:04,971 INFO  [org.jboss.web] (MSC service thread 1-8) JBAS018210: Register web context: /helloworld-default

[0m [31m19:47:05,284 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/helloworld-default]] (MSC service thread 1-8) JBWEB000284: Exception starting filter LiftFilter: java.lang.VerifyError: (class: net/liftweb/util/SecurityHelpers$class, method: hash256 signature: (Lnet/liftweb/util/SecurityHelpers;Ljava/lang/String;)Ljava/lang/String;) Incompatible object argument for function call

at net.liftweb.util.Helpers$.<init>(Helpers.scala:34) [lift-util_2.10-2.5-M4.jar:2.5-M4]

at net.liftweb.util.Helpers$.<clinit>(Helpers.scala) [lift-util_2.10-2.5-M4.jar:2.5-M4]

 

I tried building Lift-2.5-M4 against Scala-2.10.0 my self just in case, but it didn't help... Still stuck...

[Galder Zamarreño]

Final post of the day. The issue can be replicated both from running my Arquillian test from IDE (IntelliJ) or command line (Maven).

I have a branch I can push if anyone wanna give it a go.

Right now, the only explanation I can find to it is a compiler bug, but I'm no expert on that topic, and if it was a compiler bug, it would affect everyone using Scala 2.10 + Lift 2.5-M4, right?

I get the feeling this should be reproducible by calling up this filter from a unit test with the right parameters...

Cheers,

[Galder Zamarreño]

Ok, this is a bit spooky now. I've created a unit test like this: https://gist.github.com/galderz/4718488

And trying to compile that with:

      <dependency>

         <groupId>javax.servlet</groupId>

         <artifactId>servlet-api</artifactId>

         <version>2.5</version>

         <scope>test</scope>

      </dependency>

      <dependency>

         <groupId>org.jboss.web</groupId>

         <artifactId>jbossweb</artifactId>

         <version>7.2.0.Alpha2</version>

         <scope>test</scope>

      </dependency>

Breaks the Scala compiler in the IDE (Idea 12.0.3) with a NullPointerException, saying that the class file is broken. See screenshot in:

https://dl.dropbox.com/u/6148072/Screen%20Shot%202013-02-05%20at%2011.57.29%20PM.png

The issue also present when trying to compile from command line:

[INFO] --- scala-maven-plugin:3.1.3:testCompile (default) @ escalante-testsuite-lift ---

[INFO] /Users/g/Go/code/escalante.git/modules/lift/src/it/testsuite/src/test/scala:-1: info: compiling

[INFO] Compiling 8 source files to /Users/g/Go/code/escalante.git/modules/lift/src/it/testsuite/target/test-classes at 1360105257571

[WARNING] warning: Class javax.servlet.FilterRegistration not found - continuing with a stub.

[ERROR] error: error while loading ApplicationFilterConfig, class file '/Users/g/.m2/repository/org/jboss/web/jbossweb/7.2.0.Alpha2/jbossweb-7.2.0.Alpha2.jar(org/apache/catalina/core/ApplicationFilterConfig.class)' is broken

[INFO] (class java.lang.NullPointerException/)

[WARNING] warning: Class javax.servlet.SessionTrackingMode not found - continuing with a stub.

[ERROR] error: error while loading StandardContext, class file '/Users/g/.m2/repository/org/jboss/web/jbossweb/7.2.0.Alpha2/jbossweb-7.2.0.Alpha2.jar(org/apache/catalina/core/StandardContext.class)' is broken

[INFO] (class java.lang.NullPointerException/)

[ERROR] /Users/g/Go/code/escalante.git/modules/lift/src/it/testsuite/src/test/scala/io/escalante/test/lift/helloworld/Boo.scala:23: error: org.apache.catalina.core.StandardContext does not have a constructor

[ERROR]     val cfg = new ApplicationFilterConfig(new StandardContext(), null)

Maybe the problem is somehow the combination of Tomcat and Scala 2.10?

[Andreas Joseph Krogh]

Have you tried with:

 

<dependency>
  <groupId>org.apache.tomcat</groupId>
  <artifactId>tomcat-catalina</artifactId>
  <version>7.0.21</version>
</dependency>

 

The StandardContext in there definitely has a default-constructor...

[Galder Zamarreño]

The problem there was that "javax.servlet.FilterRegistration not found", and that's a class only present in Servlet 3.0 jars.

Once I imported Servlet 3.0 jars, the unit test worked fine.

It's funny though how weirdly Scala compiler failed, with a NullPointerException...

So, if Lift 2.5-M4 is compiling against Servlet 2.5 and (maybe) expecting only this library version, maybe all this issue is somehow related to this javax.servlet version difference??

Thoughts?

[Diego Medina]

> So, if Lift 2.5-M4 is compiling against Servlet 2.5 and (maybe) expecting
> only this library version, maybe all this issue is somehow related to this
> javax.servlet version difference??
>

So, do you get this error even on 2.9.2 ?

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

[Galder Zamarreño]

On Wednesday, 6 February 2013 04:51:57 UTC+1, fmpwizard wrote:

> So, if Lift 2.5-M4 is compiling against Servlet 2.5 and (maybe) expecting
> only this library version, maybe all this issue is somehow related to this
> javax.servlet version difference??
>

So, do you get this error even on 2.9.2 ?

No, it works fine with Lift 2.5-M4 and Scala 2.9.2. So, the issue seems to point at Scala 2.10.

Guys, I've run out of ideas. I tried to replicate the issue in a unit test, where I tried to replicate the same conditions but no luck.

I need to finish what I'm doing at the moment and once I'm finished with it I can post instructions to replicate the issue given a Git repo+branch.

Thanks everyone for the help :)

Cheers,

[Peter Petersson]

Hmm I think you are one to something here, interesting to here your response on Diegos question. I have deploy problems only on 2.10 on the Geronimo

 app server and I just noticed that I have wrong servlet api pulled in, however the same setup works on 2.9.2. I will as soon as i get time update the servlet api and test deploy.

Thanks for catching this hopefully it will resolve this filter :)

best regards

  Peter Petersson

2013/2/6 Diego Medina <di...@fmpwizard.com>

[Peter Petersson]

As Geronimo 3.0 is using Tomcat 7 and tomcat 7 is using the servlet 3.0 api I changed my provided settings for servlet api from 2.5 to 3.0.1 but I still get exception starting filter LiftFilter when i compile my app with scala 2.10.0

Whats really strange is that after the first deployment error I tried again but after some extra cleanup (sbt clean reboot) and the second time I get another "Exception starting filter LiftFilter" NoClassDefFoundError so this is really strange :( see bellow.
I remember to have had booth thous errors in previous tries.

Still I will keep the 3.0 setting as should be okey.

If I get time this weekend I will try with a locally compiled 2.10 lift.

best regards
  Peter Petersson

2013-02-06 21:55:59,640 INFO  [KernelContextGBean] bound gbean se.media4u101/fobo-lift-template-demo/1.0/war?J2EEApplication=null,WebModule=se.media4u101/fobo-lift-template-demo/1.0/war,j2eeType=ValidatorFactory,name=ValidatorFactory at name jca:/se.media4u101/fobo-lift-template-demo/ValidatorFactory/ValidatorFactory
2013-02-06 21:56:00,263 ERROR [[/fobo-lift-template-demo]] Exception starting filter LiftFilter
java.lang.NoClassDefFoundError: scala/Predef$ArrowAssoc$
    at net.liftweb.common.BoxTrait$class.$init$(Box.scala:62)
    at net.liftweb.common.Box$.<init>(Box.scala:49)
    at net.liftweb.common.Box$.<clinit>(Box.scala)
    at net.liftweb.util.Props$.mode$lzycompute(Props.scala:111)
    at net.liftweb.util.Props$.mode(Props.scala:110)
    at net.liftweb.util.Props$.devMode$lzycompute(Props.scala:144)
    at net.liftweb.util.Props$.devMode(Props.scala:144)
    at net.liftweb.http.LiftRules$.<init>(LiftRules.scala:79)
    at net.liftweb.http.LiftRules$.<clinit>(LiftRules.scala)

    at net.liftweb.http.provider.servlet.ServletFilterProvider$class.init(ServletFilterProvider.scala:38)
    at net.liftweb.http.LiftFilter.init(LiftServlet.scala:922)

    at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:277)
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:258)
    at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:382)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:103)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4638)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5294)
    at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:121)
    at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:722)
    at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
    at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
    at org.apache.geronimo.tomcat.GeronimoStandardContext.startInternal(GeronimoStandardContext.java:459)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
    at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:310)
    at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:567)
    at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
    at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
    at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
    at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
    at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
    at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
    at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
    at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
    at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:569)
    at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
    at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:466)
    at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:225)
    at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:710)
    at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:689)
    at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67)
    at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.ClassNotFoundException: scala.Predef$ArrowAssoc$

second try cleanup sbt reboot

2013-02-06 22:18:02,343 INFO  [KernelContextGBean] bound gbean se.media4u101/fobo-lift-template-demo/1.0/war?J2EEApplication=null,WebModule=se.media4u101/fobo-lift-template-demo/1.0/war,j2eeType=ValidatorFactory,name=ValidatorFactory at name jca:/se.media4u101/fobo-lift-template-demo/ValidatorFactory/ValidatorFactory
2013-02-06 22:18:03,178 ERROR [[/fobo-lift-template-demo]] Exception starting filter LiftFilter
java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/BaseNCodec

    at net.liftweb.util.Helpers$.<init>(Helpers.scala:34)

    at net.liftweb.util.Helpers$.<clinit>(Helpers.scala)
    at net.liftweb.http.LiftRules.<init>(LiftRules.scala:165)
    at net.liftweb.http.LiftRules$.prodInstance$lzycompute(LiftRules.scala:77)
    at net.liftweb.http.LiftRules$.prodInstance(LiftRules.scala:77)

    at net.liftweb.http.LiftRules$.realInstance(LiftRules.scala:86)

    at net.liftweb.http.LiftRulesMocker$.toLiftRules(LiftRules.scala:49)
    at net.liftweb.http.provider.servlet.ServletFilterProvider$class.init(ServletFilterProvider.scala:38)
    at net.liftweb.http.LiftFilter.init(LiftServlet.scala:922)

    at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:277)
    at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:258)
    at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:382)
    at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:103)
    at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4638)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5294)
    at org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:121)
    at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:722)
    at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
    at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
    at org.apache.geronimo.tomcat.GeronimoStandardContext.startInternal(GeronimoStandardContext.java:459)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
    at org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:310)
    at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:567)
    at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1000)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:271)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
    at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:555)
    at org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:110)
    at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:145)
    at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:119)
    at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
    at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:45)
    at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:301)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:105)
    at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:127)
    at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:569)
    at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:386)
    at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:466)
    at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:225)
    at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:710)
    at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:689)
    at org.apache.geronimo.deployment.plugin.local.StartCommand.run(StartCommand.java:67)
    at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.codec.binary.BaseNCodec
    at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:467)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
    at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
    at org.apache.geronimo.hook.equinox.GeronimoClassLoader.loadClass(GeronimoClassLoader.java:85)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    ... 47 more

[Galder Zamarreño]

I'm not sure but looks to me you have commons-codec missing there.

BaseNCodec appears to be newish class, and in fact this Lift version seems to depend on commons-codec-1.6.jar

Cheers

[Peter Petersson]

Yea I have noticed and I have already investigated that and it should work as it works on the 2.9.2 build with the same app code and target.
I have also looked into Lift and the dependencies on commons-codec is the same for the 2.10.0 and 2.9.2 builds and the common codec method calls seems the same too.

best regards
  Peter

[Galder Zamarreño]

Very odd.

Just a side note (and a little plug if I may...): 

<plug>

once this 2.10 stuff is sorted, it'd be great if you could give Escalante a try (as opposed to Geronimo) ;)

Documentation explains what Escalante is so far trying to improve about deployment/runtime of Lift applications: 

http://escalante.io/docs/#escalante_for_lift_web_applications

The quickstarts (http://escalante.io/quickstarts/) can help you figure how to get your app running in Escalante in an optimum way.

Note that your app should "just work" if you deploy to Escalante, but it's worth doing some work to make it run more optimally :)

For next version, I'd like to show how to do clustering of Lift apps in Escalante btw.

</plug>

Cheers!

[Richard Dallaway]

In case it helps, I'm trying to work my way up to reproducing this problem.  So far, I've tried M4 for Scala 2.10 in a Tomcat 7 server and JDK 7, and that started up ok (session here: https://gist.github.com/d6y/4750095)

I'll try one of the bigger containers next.

Question: does this only happen for projects built with Maven or does it happen with SBT too?

Richard

[Richard Dallaway]

For Geronimo I can reproduce this problem too with an SBT-build Lift app under JDK 1.7.

For those following along, I downloaded geronimo-tomcat7-javaee6-3.0.0. To configure it I had to do three things:

1. export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home

2. export JAVA_OPTS="-XX:MaxPermSize=512m"

3. edit geronimo-tomcat7-javaee6-3.0.0/var/config/config-substitutions.properties and replace references to 0.0.0.0 with 127.0.0.1

The server would then start from the bin directory with ./geronimo run

To deploy....

I took the latest ZIP from liftweb.net, took the lift_blank application, and added a configuration file:

$ cat > src/main/webapp/WEB-INF/geronimo-web.xml

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1">

<environment>

 <moduleId>         

  <groupId>my.app</groupId>

  <artifactId>app1</artifactId>

  <version>1.0</version>

   <type>war</type>

 </moduleId>    

</environment>

 <context-root>/hello</context-root>

</web-app>

I copied this modified lift_blank and left one alone (for 2.9) and modified the other's build.sbt for 2.10

I ran sbt package in each to produce the WAR files.

I tried to deploy 2.10:

./deploy --user system --password manager deploy /Users/richard/tmp/weird/blank_210/target/scala-2.10/lift-2.5-starter-template_2.10-0.0.1.war

 

This produced the error that has been mentioned (https://gist.github.com/d6y/4750391).

Doing:

./deploy --user system --password manager redeploy /Users/richard/tmp/weird/blank_292/target/scala-2.9.1/lift-2.5-starter-template_2.9.1-0.0.1.war

...that worked and deployed the app to 127.0.0.1:8080/hello without error.

From what I can tell, the 2.9 and 2.10 versions are build from the source. The commons codec is the same for both versions, and is the same for the version included in Geronimo.

I also extracted the two WAR files and compared the contents with...

find . -type f -exec md5 {} \; | sort 

...in each extracted WAR file and the diff showed what you'd expect. Namely, the .classes were different, the Lift libraries were different, and the Scala dependencies (scala-library.jar) where different.  https://gist.github.com/d6y/4750405

More head scratching time required....

Richard

[Richard Dallaway]

I've reproduced this problem without reference to Lift.

I built a servlet filter which references commons-codec and it fails to deploy in Geronimo with Scala 2.10 but successes with 2.9.2

The project and detailed steps to reproduce are here: 

https://github.com/d6y/geronimo_codec

Is anyone on this lift involved in the Geronimo community and want to take this forward to them?

Richard

[Jeppe Nejsum Madsen]

On Mon, Feb 11, 2013 at 10:59 PM, Richard Dallaway <ric...@dallaway.com> wrote:

I've reproduced this problem without reference to Lift.

I built a servlet filter which references commons-codec and it fails to deploy in Geronimo with Scala 2.10 but successes with 2.9.2

The project and detailed steps to reproduce are here: 

https://github.com/d6y/geronimo_codec

Is anyone on this lift involved in the Geronimo community and want to take this forward to them?

Could it also be a problem with the 2.10 compiler?

/Jeppe

[Richard Dallaway]

Possibly. My first port of call would be the Geronimo engineers to see if they can shed any light on it.  But I don't use Geronimo, so won't be taking this forward with any urgency.

Richard

 

/Jeppe

[Richard Dallaway]

The thing that's bothering me most is that it deploys just fine under Tomcat 7.  I'll join the Geronimo mailing list and see what they say.

[Peter Petersson]

This is great progress thanks for digging in to this.

best regards Peter Petersson

2013/2/12 Richard Dallaway <ric...@dallaway.com>

[Andreas Joseph Krogh]

På tirsdag 12. februar 2013 kl. 13:48:13, skrev Peter Petersson <peterss...@gmail.com>:

This is great progress thanks for digging in to this.

 

I've tried to deploy my app (lift-2.5-m4 + Scala-2.10) in a standalone Tomcat7-instance and it blows up with a different error than when running the tomcat7-maven-plugin.

 

Standalone tomcat7.

 

SEVERE: Exception starting filter LiftProxyFilter

java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/BaseNCodec
        at net.liftweb.util.Helpers$.<init>(Helpers.scala:34)
        at net.liftweb.util.Helpers$.<clinit>(Helpers.scala)
        at net.liftweb.http.LiftRules.<init>(LiftRules.scala:165)
        at net.liftweb.http.LiftRules$.prodInstance$lzycompute(LiftRules.scala:77)
        at net.liftweb.http.LiftRules$.prodInstance(LiftRules.scala:77)

        at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64)
        at net.liftweb.common.EmptyBox.openOr(Box.scala:644)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRules$.realInstance(LiftRules.scala:85)

        at net.liftweb.http.LiftRulesMocker$.toLiftRules(LiftRules.scala:49)
        at net.liftweb.http.provider.servlet.ServletFilterProvider$class.init(ServletFilterProvider.scala:38)

 

tomcat7-maven-plugin:

 

Feb 12, 2013 1:54:20 PM org.apache.catalina.core.StandardContext filterStart

SEVERE: Exception starting filter LiftProxyFilter

java.lang.VerifyError: (class: net/liftweb/util/SecurityHelpers$class, method: md5 signature: (Lnet/liftweb/util/SecurityHelpers;Ljava/lang/String;)Ljava/lang/String;) Incompatible object argument for function call

        at net.liftweb.util.Helpers$.<init>(Helpers.scala:34)
        at net.liftweb.util.Helpers$.<clinit>(Helpers.scala)
        at net.liftweb.http.LiftRules.<init>(LiftRules.scala:165)
        at net.liftweb.http.LiftRules$.prodInstance$lzycompute(LiftRules.scala:77)
        at net.liftweb.http.LiftRules$.prodInstance(LiftRules.scala:77)

        at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9$$anonfun$apply$2.apply(LiftRules.scala:64)
        at net.liftweb.common.EmptyBox.openOr(Box.scala:644)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRulesMocker$$anonfun$9.apply(LiftRules.scala:64)
        at net.liftweb.http.LiftRules$.realInstance(LiftRules.scala:85)

        at net.liftweb.http.LiftRulesMocker$.toLiftRules(LiftRules.scala:49)
        at net.liftweb.http.provider.servlet.ServletFilterProvider$class.init(ServletFilterProvider.scala:38)
        at net.liftweb.http.LiftFilter.init(LiftServlet.scala:922)

[Richard Dallaway]

Thanks for that -- which Tomcat is that?

I notice Geronimo use 7.0.27 but I've been using 7.0.35

Richard

--

[Andreas Joseph Krogh]

På onsdag 13. februar 2013 kl. 10:45:42, skrev Richard Dallaway <ric...@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

[Richard Dallaway]

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 

--

[Andreas Joseph Krogh]

På onsdag 13. februar 2013 kl. 12:05:39, skrev Richard Dallaway <ric...@dallaway.com>:

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

 

I've tried to reproduce the problem using this example-project: https://github.com/andreak/on-example-rpm but it somehow work OK so I'm unable to reproduce at the moment....

 

I'll try to find some time to look closer.

[Galder Zamarreño]

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,

[Richard Dallaway]

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

[Peter Petersson]

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

[Peter Petersson]

As pointed out on the Geronimo User list having the import-package setting in the deployment description is a way better solution to the library version conflict (and hence class loading problems) between the app and the container (I tried it before but most have missed the * at the end or something) it dose how ever not explain why this conflict manifests itself while building the app with scala 2.10 and not with 2.9.  

<sys:import-package> !org.apache.commons.codec*</sys:import-package>

best regards
   Peter Petersson

[Richard Dallaway]

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? :-)

Richard

1 https://cwiki.apache.org/GMOxDOC22/classloading.html

[Peter Petersson]

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

[Galder Zamarreño]

Sorted for Escalante too!!! :D 

Thanks all for the hints provided cos it was a commons-codec issue on my side too.

The problem was that the test war I was using had commons-codec 1.4 as a transitive dependency of Selenium (I hate transitive dependencies...), so when no commons-codec 1.6 was in, I was also getting the CNFE that you saw. But if I added commons-codec 1.6 to the war, you had the two commons-codec jars and it broke in that funny way.

I still think there's a problem in Scala 2.10 since it's very confusing how it reacts.

Glad to have Escalante working with Scala 2.10 though! 0.3.0 version will contain support for it :)

Once again, thanks all :)

[Andreas Joseph Krogh]

På tirsdag 19. februar 2013 kl. 23:10:12, skrev Galder Zamarreño <gal...@zamarreno.com>:

Sorted for Escalante too!!! :D 

 

Thanks all for the hints provided cos it was a commons-codec issue on my side too.

 

The problem was that the test war I was using had commons-codec 1.4 as a transitive dependency of Selenium (I hate transitive dependencies...), so when no commons-codec 1.6 was in, I was also getting the CNFE that you saw. But if I added commons-codec 1.6 to the war, you had the two commons-codec jars and it broke in that funny way.

 

I still think there's a problem in Scala 2.10 since it's very confusing how it reacts.

 

Glad to have Escalante working with Scala 2.10 though! 0.3.0 version will contain support for it :)

 

Once again, thanks all :)

 

My issue was resolved too by upgrading to commons-codec-1.6. Bootstrapping with tomcat7 and tomcat7-maven-plugin is now working.

 

What stops me from upgrading to Scala-2.10 now is https://issues.scala-lang.org/browse/SI-7151

[Naftoli Gugenheim]

You could always use the scala 2.10 reflection api...

 

--

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

[Andreas Joseph Krogh]

På onsdag 20. februar 2013 kl. 06:43:56, skrev Naftoli Gugenheim <nafto...@gmail.com>:

You could always use the scala 2.10 reflection api...

 

My specific problem is JAVA-interop, so no Scala-reflection here...

[Galder Zamarreño]

Not sure if you tried, but what if Moo non-final?

[Galder Zamarreño]

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:

[Andreas Joseph Krogh]

På onsdag 20. februar 2013 kl. 09:07:36, skrev Galder Zamarreño <gal...@zamarreno.com>:

Not sure if you tried, but what if Moo non-final?

 

Non-final case classes, and obviously not final ones either as my bugreport shows,  are not final at the JVM-level, even though in 2.10 your not allowed to extend them anymore as you were in 2.9.

[Peter Petersson]

2013/2/20 Galder Zamarreño <gal...@zamarreno.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 :)

Nice to here it works great on Escalante :).

The thing is that Scala 2.10 as opposed to the 2.9.x may be the one allowing the JEE container to do the right thing ;) so there may be other situations with other clashing librarys even in JBoss.

I found this class loading problem in Geronimo3 but the Geronimo classloader delegation follows the Java EE 5 specifications, and the normal behavior is to load classes from a parent classloader before checking the current classloader. I would expect JBoss to follow the same standard though I have not checked.

Checking the parent classloader first may in some case (like this one) present a problem and that's why Geronimo and other JEE app servers have a advanced classloading system that allow you to manipulate the default behavior in various ways (like hiding clashing libraries present in the parent classloder). 

If a similar problem should arise in JBoss the most brute force setting would be to use

JBoss - java2ParentDelegation=false

But in the long run that may not be a good idea and there are most likely some more fin grained setting available in JBoss for hiding a troublesome library, like the one i use in Geronimo3

<sys:import-package> !org.apache.commons.codec*</sys:import-package>

to hide the containers older commons codec.

The following [1] is a good article on the subject.

[1] http://www.theserverside.com/news/1364663/Advanced-Classloading-in-J2EE

[Galder Zamarreño]

To quote my colleagues who wrote AS7 (see http://www.jboss.org/jbossas):

"Hierarchical classloaders are problematic, often causing failed deployments and quirky behavior. The time has come to say goodbye to the parent delegation model and find the path to modularity (i.e. sane classloading)."

"AS 7 does classloading right. It uses JBoss Modules to provide true application isolation, hiding server implementation classes from the application …."

JBoss AS 7.1 is a certified EE6 server, so I don't think your statement is entirely correct ;)

To reiterate what I said earlier: If you want a server to deploy Lift applications where the application server does no leak server libraries to deployments, choose Escalante :)

Cheers,

[Peter Petersson]

2013/2/21 Galder Zamarreño <gal...@zamarreno.com>

To quote my colleagues who wrote AS7 (see http://www.jboss.org/jbossas):

"Hierarchical classloaders are problematic, often causing failed deployments and quirky behavior. The time has come to say goodbye to the parent delegation model and find the path to modularity (i.e. sane classloading)."

"AS 7 does classloading right. It uses JBoss Modules to provide true application isolation, hiding server implementation classes from the application …."

JBoss AS 7.1 is a certified EE6 server, so I don't think your statement is entirely correct ;)

As is Geronimo 3 ;)  Cheers Peter