I've run into a WAR deployment problem that I'm hoping someone here can help me understand and resolve.
I've put together a small web application (just a servlet filter) which references Apache Commons Codec. This project uses Scala. When build with Scala 2.9 it deploys to Geronimo and runs. When build with Scala 2.10 it does not deploy. However, both versions happily deploy and run under Tomcat 7.
The exception is:
ERROR [[/hello]] Exception starting filter MyFilter
at java.lang.Class.forName0(Native Method)
I've put the project on github with details of steps to reproduce and the full stack trace and WAR contents:
Any suggestions for how I can resolve this one?
Thanks Richard for putting this minimal Scala 2.9/2.10 example together to demonstrate this "class loading problem".
I took a peek at it and found a way to get around the problem found with the 2.10 build (see below), however I still have not found the direct cause of the problem and hope that someone in the Geronimo community could help narrow it down a bit more, It would be greatly appreciated ( David J ? ;) ).
To make the 2.10 build deploy and start correctly, as the Scala 2.9 build dose, I added the inverse-classloading  setting to the deployment descriptor (for the Scala 2.10 build, its not needed when building with Scala 2.9), this may however not be a ultimate solution in all situations so if anyone have a better solution or a suggestion on how to narrow it down pleas let us know.
On 02/12/2013 11:05 AM, Richard Dallaway wrote:
Another approach would be to hide the packages provided by server. It's a better way to avoid the liberay conflict between the app and server.
you can also do the same with this
<sys:hidden-classes> sys:classFilterType </sys:hidden-classes>
if you are using geornimo 2.x
On Sat, Feb 16, 2013 at 7:45 PM, Peter Petersson <[hidden email]> wrote:
On 02/16/2013 01:36 PM, Shawn Jiang wrote:
Yes, thank you, I tried that but most have forgot the * at the end or something. This is clearly a better way to solve the library version conflict.
It would however be good to know why the conflict only manifests itself while building the app with scala 2.10 and not with 2.9 ;) In bot h builds the app uses common codec v1.6.
I guess the call trace is different between 2.10 and 2.9. and the call trace in 2.9 avoid this conflict somehow.
On Sat, Feb 16, 2013 at 8:59 PM, Peter Petersson <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|