WAR classloading problem

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

WAR classloading problem

Michel Drescher
Folks,

I have a weird configuration situation:

I deploy a servlet (named, say "Child"), which is a subclass of an  
abstract servlet ("Parent"). The WAR is named "servlet.war".

The problem is here that Jetty does not find "Parent", throwing a  
"NoClassDefFoundError" whether I package "Parent.class" in WEB-INF/
classes (the .class file itself) or in WEB-INF/lib (within a .jar  
file). The only way to get Jetty to load "Parent" is to put it in the  
system class path ($CLASSPATH of the Java App that embeds Jetty).

The code to run Jetty is as follows:
---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
----------
org.mortbay.jetty.Server server = new Server();
// add an SSL listener on port 8443
SSLListener myListener = new SSLListener();
myListener.setPort( 8443 );
myListener.setKeystore( "server.jks" ); // also sets the trust store
myListener.setPassword( "server" );     // also sets the trust store  
password
myListener.setKeyPassword( "server" );
myListener.setNeedClientAuth( true );
server.addListener( myListener );
server.addWebApplication( "/parhttp", "./servlet.war" );
server.start();
---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
----------
NOTES:
a) The SSLListener is my own subclass of Jetty's SSL listener as I  
needed to integrate TrustManagers and KeyManagers.
b) Jetty 5.1.10 is used
c) The WAR file has been created using ant, namely its MANIFEST.MF  
file is auto-created using ant
d) The Eclipse 3.1 built-in ant is used (version 1.6.5)
e) "Parent" and "Child" are both actually located in packages that  
are typically not considered being system packages (like "javax.*");  
rather, they are located in different "org.*" packages
f) Playing around with  
"WebApplicationContext.setClassLoaderJava2Compliant(true)" does not help
g) Playing around with "WebApplicationContext.setExtractWAR(true)"  
does not help, either


WTH do I miss out here?

Thanks for any help,
Michel



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: WAR classloading problem

Michel Drescher
Hi all,

got some update, and I think the resolution is a bug in Jetty 5.1.10.

I messed around with all kinds of possible error conditions on my  
side. No success.

The confusion on my side grew as it was perfectly possible to deploy  
the very same servlet WAR in a default Jetty 5.1.10 installation, no  
errors no nothing and it worked as expected.

Then, I happened to play around again with my Java application code  
that embeds Jetty. I actually set  
"WebApplicationContext.setClassLoaderJava2Complient( false )" - and  
*BANG*, the servlet WAR deployed just fine.

Next I thoroughly checked demo.xml and jetty.xml, as well as  
org.mortbay.jetty.Server.java.
a) The configuration files both configure the "webapps" directory to  
auto-deploy all found
    web apps with Java2 compliance classloaders TURNED OFF
b) Server.java by default uses Java2 compliant classloaders for Web  
Applications

I am not sure, but I remember the default behaviour in earlier Jetty  
versions was as expected, that for Web Applications Servlet specific  
classloaders are used.

Any thoughts/comments?

Cheers,
Michel


On 23 Feb 2006, at 20:25, Michel Drescher wrote:

> Folks,
>
> I have a weird configuration situation:
>
> I deploy a servlet (named, say "Child"), which is a subclass of an  
> abstract servlet ("Parent"). The WAR is named "servlet.war".
>
> The problem is here that Jetty does not find "Parent", throwing a  
> "NoClassDefFoundError" whether I package "Parent.class" in WEB-INF/
> classes (the .class file itself) or in WEB-INF/lib (within a .jar  
> file). The only way to get Jetty to load "Parent" is to put it in  
> the system class path ($CLASSPATH of the Java App that embeds Jetty).
>
> The code to run Jetty is as follows:
> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
> ----------
> org.mortbay.jetty.Server server = new Server();
> // add an SSL listener on port 8443
> SSLListener myListener = new SSLListener();
> myListener.setPort( 8443 );
> myListener.setKeystore( "server.jks" ); // also sets the trust store
> myListener.setPassword( "server" );     // also sets the trust  
> store password
> myListener.setKeyPassword( "server" );
> myListener.setNeedClientAuth( true );
> server.addListener( myListener );
> server.addWebApplication( "/parhttp", "./servlet.war" );
> server.start();
> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
> ----------
> NOTES:
> a) The SSLListener is my own subclass of Jetty's SSL listener as I  
> needed to integrate TrustManagers and KeyManagers.
> b) Jetty 5.1.10 is used
> c) The WAR file has been created using ant, namely its MANIFEST.MF  
> file is auto-created using ant
> d) The Eclipse 3.1 built-in ant is used (version 1.6.5)
> e) "Parent" and "Child" are both actually located in packages that  
> are typically not considered being system packages (like  
> "javax.*"); rather, they are located in different "org.*" packages
> f) Playing around with  
> "WebApplicationContext.setClassLoaderJava2Compliant(true)" does not  
> help
> g) Playing around with "WebApplicationContext.setExtractWAR(true)"  
> does not help, either
>
>
> WTH do I miss out here?
>
> Thanks for any help,
> Michel
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: WAR classloading problem

jan_bartel
Michel,

The behaviour for the java2classloadingcompliance is that if
you don't explicitly specify it, it is TRUE.

In both demo.xml and jetty.xml it is left unspecified *except*
for the lines which instruct Jetty to deploy anything found
in webapps/, in which case, java2classloadingcompliance is
set to FALSE.

So, I think it is at least consistent. I don't _think_ it's changed
recently in jetty5, but I could be wrong. You could have a good
point that the default should be around the other way.

Jan



Michel Drescher wrote:

> Hi all,
>
> got some update, and I think the resolution is a bug in Jetty 5.1.10.
>
> I messed around with all kinds of possible error conditions on my  side.
> No success.
>
> The confusion on my side grew as it was perfectly possible to deploy  
> the very same servlet WAR in a default Jetty 5.1.10 installation, no  
> errors no nothing and it worked as expected.
>
> Then, I happened to play around again with my Java application code  
> that embeds Jetty. I actually set  
> "WebApplicationContext.setClassLoaderJava2Complient( false )" - and  
> *BANG*, the servlet WAR deployed just fine.
>
> Next I thoroughly checked demo.xml and jetty.xml, as well as  
> org.mortbay.jetty.Server.java.
> a) The configuration files both configure the "webapps" directory to  
> auto-deploy all found
>    web apps with Java2 compliance classloaders TURNED OFF
> b) Server.java by default uses Java2 compliant classloaders for Web  
> Applications
>
> I am not sure, but I remember the default behaviour in earlier Jetty  
> versions was as expected, that for Web Applications Servlet specific  
> classloaders are used.
>
> Any thoughts/comments?
>
> Cheers,
> Michel
>
>
> On 23 Feb 2006, at 20:25, Michel Drescher wrote:
>
>> Folks,
>>
>> I have a weird configuration situation:
>>
>> I deploy a servlet (named, say "Child"), which is a subclass of an  
>> abstract servlet ("Parent"). The WAR is named "servlet.war".
>>
>> The problem is here that Jetty does not find "Parent", throwing a  
>> "NoClassDefFoundError" whether I package "Parent.class" in WEB-INF/
>> classes (the .class file itself) or in WEB-INF/lib (within a .jar  
>> file). The only way to get Jetty to load "Parent" is to put it in  the
>> system class path ($CLASSPATH of the Java App that embeds Jetty).
>>
>> The code to run Jetty is as follows:
>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
>> ----------
>> org.mortbay.jetty.Server server = new Server();
>> // add an SSL listener on port 8443
>> SSLListener myListener = new SSLListener();
>> myListener.setPort( 8443 );
>> myListener.setKeystore( "server.jks" ); // also sets the trust store
>> myListener.setPassword( "server" );     // also sets the trust  store
>> password
>> myListener.setKeyPassword( "server" );
>> myListener.setNeedClientAuth( true );
>> server.addListener( myListener );
>> server.addWebApplication( "/parhttp", "./servlet.war" );
>> server.start();
>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
>> ----------
>> NOTES:
>> a) The SSLListener is my own subclass of Jetty's SSL listener as I  
>> needed to integrate TrustManagers and KeyManagers.
>> b) Jetty 5.1.10 is used
>> c) The WAR file has been created using ant, namely its MANIFEST.MF  
>> file is auto-created using ant
>> d) The Eclipse 3.1 built-in ant is used (version 1.6.5)
>> e) "Parent" and "Child" are both actually located in packages that  
>> are typically not considered being system packages (like  "javax.*");
>> rather, they are located in different "org.*" packages
>> f) Playing around with  
>> "WebApplicationContext.setClassLoaderJava2Compliant(true)" does not  help
>> g) Playing around with "WebApplicationContext.setExtractWAR(true)"  
>> does not help, either
>>
>>
>> WTH do I miss out here?
>>
>> Thanks for any help,
>> Michel
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  live
>> webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: WAR classloading problem

Michel Drescher
Hi Jan,

thanks for the answer.

On 24 Feb 2006, at 14:18, Jan Bartel wrote:

> Michel,
>
> The behaviour for the java2classloadingcompliance is that if you  
> don't explicitly specify it, it is TRUE.
>
> In both demo.xml and jetty.xml it is left unspecified *except*
> for the lines which instruct Jetty to deploy anything found
> in webapps/, in which case, java2classloadingcompliance is
> set to FALSE.
>
> So, I think it is at least consistent. I don't _think_ it's changed
> recently in jetty5, but I could be wrong. You could have a good
> point that the default should be around the other way.

While this behaviour may be consistent, it is IMHO unlogic. :-)

Yes indeed, I think Jetty should behave the other way round  
_for_WAR_deployments_.

When I develop and deploy a Web Application, I expect a J2EE  
environment, which includes a servlet specific classloader (that  
recognises and loads classes from WEB-INF/lib). Jetty does not  
provide me with that environment, unless I explicitly activate it.  
Rather, the full J2EE environment should be provided _implicitly_ to  
the developer/deployer. (The fact that the config files disable Java2  
compliant classloaders does not qualify for implicitness, it is the  
API that lacks this implicitness.)

For anything else, i.e. HTTPHandlers/Filters and all other stuff in  
Jetty, Java2 compliant classloaders should be used.

So, as a summary, I indeed incline to shout "Bug! Bug" Bug!" ;-)

Cheers,
Michel

N.B.: In case anybody thinks the post is too harsh in rhetorics, my  
apologies. I tried to argue towards a change of the default Jetty  
behaviour. And, effortwise, the change really should affect only a  
couple of code lines.

>
>
> Jan
>
>
>
> Michel Drescher wrote:
>> Hi all,
>> got some update, and I think the resolution is a bug in Jetty 5.1.10.
>> I messed around with all kinds of possible error conditions on my  
>> side. No success.
>> The confusion on my side grew as it was perfectly possible to  
>> deploy  the very same servlet WAR in a default Jetty 5.1.10  
>> installation, no  errors no nothing and it worked as expected.
>> Then, I happened to play around again with my Java application  
>> code  that embeds Jetty. I actually set  
>> "WebApplicationContext.setClassLoaderJava2Complient( false )" -  
>> and  *BANG*, the servlet WAR deployed just fine.
>> Next I thoroughly checked demo.xml and jetty.xml, as well as  
>> org.mortbay.jetty.Server.java.
>> a) The configuration files both configure the "webapps" directory  
>> to  auto-deploy all found
>>    web apps with Java2 compliance classloaders TURNED OFF
>> b) Server.java by default uses Java2 compliant classloaders for  
>> Web  Applications
>> I am not sure, but I remember the default behaviour in earlier  
>> Jetty  versions was as expected, that for Web Applications Servlet  
>> specific  classloaders are used.
>> Any thoughts/comments?
>> Cheers,
>> Michel
>> On 23 Feb 2006, at 20:25, Michel Drescher wrote:
>>> Folks,
>>>
>>> I have a weird configuration situation:
>>>
>>> I deploy a servlet (named, say "Child"), which is a subclass of  
>>> an  abstract servlet ("Parent"). The WAR is named "servlet.war".
>>>
>>> The problem is here that Jetty does not find "Parent", throwing  
>>> a  "NoClassDefFoundError" whether I package "Parent.class" in WEB-
>>> INF/ classes (the .class file itself) or in WEB-INF/lib (within  
>>> a .jar  file). The only way to get Jetty to load "Parent" is to  
>>> put it in  the system class path ($CLASSPATH of the Java App that  
>>> embeds Jetty).
>>>
>>> The code to run Jetty is as follows:
>>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
>>> ----------
>>> org.mortbay.jetty.Server server = new Server();
>>> // add an SSL listener on port 8443
>>> SSLListener myListener = new SSLListener();
>>> myListener.setPort( 8443 );
>>> myListener.setKeystore( "server.jks" ); // also sets the trust store
>>> myListener.setPassword( "server" );     // also sets the trust  
>>> store password
>>> myListener.setKeyPassword( "server" );
>>> myListener.setNeedClientAuth( true );
>>> server.addListener( myListener );
>>> server.addWebApplication( "/parhttp", "./servlet.war" );
>>> server.start();
>>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
>>> ----------
>>> NOTES:
>>> a) The SSLListener is my own subclass of Jetty's SSL listener as  
>>> I  needed to integrate TrustManagers and KeyManagers.
>>> b) Jetty 5.1.10 is used
>>> c) The WAR file has been created using ant, namely its  
>>> MANIFEST.MF  file is auto-created using ant
>>> d) The Eclipse 3.1 built-in ant is used (version 1.6.5)
>>> e) "Parent" and "Child" are both actually located in packages  
>>> that  are typically not considered being system packages (like  
>>> "javax.*"); rather, they are located in different "org.*" packages
>>> f) Playing around with  
>>> "WebApplicationContext.setClassLoaderJava2Compliant(true)" does  
>>> not  help
>>> g) Playing around with "WebApplicationContext.setExtractWAR
>>> (true)"  does not help, either
>>>
>>>
>>> WTH do I miss out here?
>>>
>>> Thanks for any help,
>>> Michel
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking  
>>> scripting  language
>>> that extends applications into web and mobile media. Attend the  
>>> live webcast
>>> and join the prime developer group breaking into this new coding  
>>> territory!
>>> http://sel.as-us.falkag.net/sel?  
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Jetty-support mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: WAR classloading problem

Greg Wilkins-5

Well Michel,

I'm open to considering changing the default....  

but I do take a little objection to the shouting of bug bug bug!

The (IMHO stupid) inverted class loading behaviour of servlet containers
is not a MUST, rather a recommendation:

 "It is recommended also that the application class loader be implemented so
  that classes and resources packaged within the WAR are loaded in preference to
  classes and resources residing in container-wide library JARs."

The default has been the way it is for *OVER A DECADE* and you are the
first person to complain.  Conversely, lots of people have complained about
the hassles of java commons logging when this is turned on.

So as Jetty 5 is soon to be replaced by Jetty 6 as the stable release,
I'm not that inclined to change it in Jetty 5 -why rock the boat, when
perhaps a bit better doco and FAQs can fix it.

But I have been thinking that it should probably be changed for Jetty 6.
In fact I have already changed the default in Jetty 6.

cheers


Michel Drescher wrote:

> Hi Jan,
>
> thanks for the answer.
>
> On 24 Feb 2006, at 14:18, Jan Bartel wrote:
>
>> Michel,
>>
>> The behaviour for the java2classloadingcompliance is that if you
>> don't explicitly specify it, it is TRUE.
>>
>> In both demo.xml and jetty.xml it is left unspecified *except*
>> for the lines which instruct Jetty to deploy anything found
>> in webapps/, in which case, java2classloadingcompliance is
>> set to FALSE.
>>
>> So, I think it is at least consistent. I don't _think_ it's changed
>> recently in jetty5, but I could be wrong. You could have a good
>> point that the default should be around the other way.
>
>
> While this behaviour may be consistent, it is IMHO unlogic. :-)
>
> Yes indeed, I think Jetty should behave the other way round
> _for_WAR_deployments_.
>
> When I develop and deploy a Web Application, I expect a J2EE
> environment, which includes a servlet specific classloader (that
> recognises and loads classes from WEB-INF/lib). Jetty does not  provide
> me with that environment, unless I explicitly activate it.  Rather, the
> full J2EE environment should be provided _implicitly_ to  the
> developer/deployer. (The fact that the config files disable Java2
> compliant classloaders does not qualify for implicitness, it is the  API
> that lacks this implicitness.)
>
> For anything else, i.e. HTTPHandlers/Filters and all other stuff in
> Jetty, Java2 compliant classloaders should be used.
>
> So, as a summary, I indeed incline to shout "Bug! Bug" Bug!" ;-)
>
> Cheers,
> Michel
>
> N.B.: In case anybody thinks the post is too harsh in rhetorics, my
> apologies. I tried to argue towards a change of the default Jetty
> behaviour. And, effortwise, the change really should affect only a
> couple of code lines.
>
>>
>>
>> Jan
>>
>>
>>
>> Michel Drescher wrote:
>>
>>> Hi all,
>>> got some update, and I think the resolution is a bug in Jetty 5.1.10.
>>> I messed around with all kinds of possible error conditions on my  
>>> side. No success.
>>> The confusion on my side grew as it was perfectly possible to
>>> deploy  the very same servlet WAR in a default Jetty 5.1.10
>>> installation, no  errors no nothing and it worked as expected.
>>> Then, I happened to play around again with my Java application  code
>>> that embeds Jetty. I actually set  
>>> "WebApplicationContext.setClassLoaderJava2Complient( false )" -  and
>>> *BANG*, the servlet WAR deployed just fine.
>>> Next I thoroughly checked demo.xml and jetty.xml, as well as  
>>> org.mortbay.jetty.Server.java.
>>> a) The configuration files both configure the "webapps" directory
>>> to  auto-deploy all found
>>>    web apps with Java2 compliance classloaders TURNED OFF
>>> b) Server.java by default uses Java2 compliant classloaders for  Web
>>> Applications
>>> I am not sure, but I remember the default behaviour in earlier
>>> Jetty  versions was as expected, that for Web Applications Servlet
>>> specific  classloaders are used.
>>> Any thoughts/comments?
>>> Cheers,
>>> Michel
>>> On 23 Feb 2006, at 20:25, Michel Drescher wrote:
>>>
>>>> Folks,
>>>>
>>>> I have a weird configuration situation:
>>>>
>>>> I deploy a servlet (named, say "Child"), which is a subclass of  an
>>>> abstract servlet ("Parent"). The WAR is named "servlet.war".
>>>>
>>>> The problem is here that Jetty does not find "Parent", throwing  a
>>>> "NoClassDefFoundError" whether I package "Parent.class" in WEB- INF/
>>>> classes (the .class file itself) or in WEB-INF/lib (within  a .jar
>>>> file). The only way to get Jetty to load "Parent" is to  put it in
>>>> the system class path ($CLASSPATH of the Java App that  embeds Jetty).
>>>>
>>>> The code to run Jetty is as follows:
>>>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
>>>> ----------
>>>> org.mortbay.jetty.Server server = new Server();
>>>> // add an SSL listener on port 8443
>>>> SSLListener myListener = new SSLListener();
>>>> myListener.setPort( 8443 );
>>>> myListener.setKeystore( "server.jks" ); // also sets the trust store
>>>> myListener.setPassword( "server" );     // also sets the trust  
>>>> store password
>>>> myListener.setKeyPassword( "server" );
>>>> myListener.setNeedClientAuth( true );
>>>> server.addListener( myListener );
>>>> server.addWebApplication( "/parhttp", "./servlet.war" );
>>>> server.start();
>>>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP  
>>>> ----------
>>>> NOTES:
>>>> a) The SSLListener is my own subclass of Jetty's SSL listener as  I
>>>> needed to integrate TrustManagers and KeyManagers.
>>>> b) Jetty 5.1.10 is used
>>>> c) The WAR file has been created using ant, namely its  MANIFEST.MF
>>>> file is auto-created using ant
>>>> d) The Eclipse 3.1 built-in ant is used (version 1.6.5)
>>>> e) "Parent" and "Child" are both actually located in packages  that
>>>> are typically not considered being system packages (like  
>>>> "javax.*"); rather, they are located in different "org.*" packages
>>>> f) Playing around with  
>>>> "WebApplicationContext.setClassLoaderJava2Compliant(true)" does
>>>> not  help
>>>> g) Playing around with "WebApplicationContext.setExtractWAR (true)"
>>>> does not help, either
>>>>
>>>>
>>>> WTH do I miss out here?
>>>>
>>>> Thanks for any help,
>>>> Michel
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking  scripting
>>>> language
>>>> that extends applications into web and mobile media. Attend the  
>>>> live webcast
>>>> and join the prime developer group breaking into this new coding  
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?
>>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>>> _______________________________________________
>>>> Jetty-support mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>> language
>>> that extends applications into web and mobile media. Attend the  live
>>> webcast
>>> and join the prime developer group breaking into this new coding
>>> territory!
>>> http://sel.as-us.falkag.net/sel?
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Jetty-support mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> language
>> that extends applications into web and mobile media. Attend the  live
>> webcast
>> and join the prime developer group breaking into this new coding
>> territory!
>> http://sel.as-us.falkag.net/sel? cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: WAR classloading problem

Michel Drescher
Hi Greg,

On 28 Feb 2006, at 20:29, Greg Wilkins wrote:

>
> Well Michel,
>
> I'm open to considering changing the default....
>
> but I do take a little objection to the shouting of bug bug bug!
>
> The (IMHO stupid) inverted class loading behaviour of servlet  
> containers
> is not a MUST, rather a recommendation:
>
>  "It is recommended also that the application class loader be  
> implemented so
>   that classes and resources packaged within the WAR are loaded in  
> preference to
>   classes and resources residing in container-wide library JARs."

Fair enough. Though it was a requirement. BTW, I indeed think it is  
necessary as web applications should be as self-contained as  
possible. Think of two web applications that must be hosted on the  
same container, but both are written so that they require two  
different versions of the same library which are totally incompatible  
to each other. Th only solution is that each web application uses its  
own packaged version of that library. (The fact that this requirement  
is broken and violated by other Java VM oddities, i.e. static  
variables and methods is left aside.) But I don't want to open a can  
of worms here...

> The default has been the way it is for *OVER A DECADE* and you are the
> first person to complain.  Conversely, lots of people have  
> complained about
> the hassles of java commons logging when this is turned on.

Considering the *order of precedence* of JAR files in a  
WebApplication class loader, you are right.

I actually ran into a slightly different problem here in that classes  
were not loaded *at all* (resulting in a ClassDefNotFoundException as  
described earlier) even though the classes were contained in a JAR  
file in the WEB-INF/lib dir of the deployed web application. The only  
way to get these classes loaded were to explicitly turn off Java2  
compliance.

To get this illustrated, I started to write a demo web app. In the  
beginning, this demo web app showed the same problem (having a class  
not loaded even though it was present in WEB-INF/lib) which could  
only be solved by disabling Java2 compliance. Unfortunately, this  
demo web app does not do anymore what I wanted it to do and left me  
in a quite puzzled state (however the original web app that caused me  
posting about this on the list still shows this behaviour).

The problem seem not to be ant related, though (referring to the ant  
FAQ).

> So as Jetty 5 is soon to be replaced by Jetty 6 as the stable release,
> I'm not that inclined to change it in Jetty 5 -why rock the boat, when
> perhaps a bit better doco and FAQs can fix it.
>
> But I have been thinking that it should probably be changed for  
> Jetty 6.
> In fact I have already changed the default in Jetty 6.

Thanks!

Cheers,
Michel


>
> cheers
>
>
> Michel Drescher wrote:
>> Hi Jan,
>>
>> thanks for the answer.
>>
>> On 24 Feb 2006, at 14:18, Jan Bartel wrote:
>>
>>> Michel,
>>>
>>> The behaviour for the java2classloadingcompliance is that if you
>>> don't explicitly specify it, it is TRUE.
>>>
>>> In both demo.xml and jetty.xml it is left unspecified *except*
>>> for the lines which instruct Jetty to deploy anything found
>>> in webapps/, in which case, java2classloadingcompliance is
>>> set to FALSE.
>>>
>>> So, I think it is at least consistent. I don't _think_ it's changed
>>> recently in jetty5, but I could be wrong. You could have a good
>>> point that the default should be around the other way.
>>
>>
>> While this behaviour may be consistent, it is IMHO unlogic. :-)
>>
>> Yes indeed, I think Jetty should behave the other way round
>> _for_WAR_deployments_.
>>
>> When I develop and deploy a Web Application, I expect a J2EE
>> environment, which includes a servlet specific classloader (that
>> recognises and loads classes from WEB-INF/lib). Jetty does not  
>> provide
>> me with that environment, unless I explicitly activate it.  
>> Rather, the
>> full J2EE environment should be provided _implicitly_ to  the
>> developer/deployer. (The fact that the config files disable Java2
>> compliant classloaders does not qualify for implicitness, it is  
>> the  API
>> that lacks this implicitness.)
>>
>> For anything else, i.e. HTTPHandlers/Filters and all other stuff in
>> Jetty, Java2 compliant classloaders should be used.
>>
>> So, as a summary, I indeed incline to shout "Bug! Bug" Bug!" ;-)
>>
>> Cheers,
>> Michel
>>
>> N.B.: In case anybody thinks the post is too harsh in rhetorics, my
>> apologies. I tried to argue towards a change of the default Jetty
>> behaviour. And, effortwise, the change really should affect only a
>> couple of code lines.
>>
>>>
>>>
>>> Jan
>>>
>>>
>>>
>>> Michel Drescher wrote:
>>>
>>>> Hi all,
>>>> got some update, and I think the resolution is a bug in Jetty  
>>>> 5.1.10.
>>>> I messed around with all kinds of possible error conditions on my
>>>> side. No success.
>>>> The confusion on my side grew as it was perfectly possible to
>>>> deploy  the very same servlet WAR in a default Jetty 5.1.10
>>>> installation, no  errors no nothing and it worked as expected.
>>>> Then, I happened to play around again with my Java application  
>>>> code
>>>> that embeds Jetty. I actually set
>>>> "WebApplicationContext.setClassLoaderJava2Complient( false )" -  
>>>> and
>>>> *BANG*, the servlet WAR deployed just fine.
>>>> Next I thoroughly checked demo.xml and jetty.xml, as well as
>>>> org.mortbay.jetty.Server.java.
>>>> a) The configuration files both configure the "webapps" directory
>>>> to  auto-deploy all found
>>>>    web apps with Java2 compliance classloaders TURNED OFF
>>>> b) Server.java by default uses Java2 compliant classloaders for  
>>>> Web
>>>> Applications
>>>> I am not sure, but I remember the default behaviour in earlier
>>>> Jetty  versions was as expected, that for Web Applications Servlet
>>>> specific  classloaders are used.
>>>> Any thoughts/comments?
>>>> Cheers,
>>>> Michel
>>>> On 23 Feb 2006, at 20:25, Michel Drescher wrote:
>>>>
>>>>> Folks,
>>>>>
>>>>> I have a weird configuration situation:
>>>>>
>>>>> I deploy a servlet (named, say "Child"), which is a subclass  
>>>>> of  an
>>>>> abstract servlet ("Parent"). The WAR is named "servlet.war".
>>>>>
>>>>> The problem is here that Jetty does not find "Parent", throwing  a
>>>>> "NoClassDefFoundError" whether I package "Parent.class" in WEB-  
>>>>> INF/
>>>>> classes (the .class file itself) or in WEB-INF/lib (within  a .jar
>>>>> file). The only way to get Jetty to load "Parent" is to  put it in
>>>>> the system class path ($CLASSPATH of the Java App that  embeds  
>>>>> Jetty).
>>>>>
>>>>> The code to run Jetty is as follows:
>>>>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP
>>>>> ----------
>>>>> org.mortbay.jetty.Server server = new Server();
>>>>> // add an SSL listener on port 8443
>>>>> SSLListener myListener = new SSLListener();
>>>>> myListener.setPort( 8443 );
>>>>> myListener.setKeystore( "server.jks" ); // also sets the trust  
>>>>> store
>>>>> myListener.setPassword( "server" );     // also sets the trust
>>>>> store password
>>>>> myListener.setKeyPassword( "server" );
>>>>> myListener.setNeedClientAuth( true );
>>>>> server.addListener( myListener );
>>>>> server.addWebApplication( "/parhttp", "./servlet.war" );
>>>>> server.start();
>>>>> ---------- SNIP ---------- SNIP ---------- SNIP ---------- SNIP
>>>>> ----------
>>>>> NOTES:
>>>>> a) The SSLListener is my own subclass of Jetty's SSL listener  
>>>>> as  I
>>>>> needed to integrate TrustManagers and KeyManagers.
>>>>> b) Jetty 5.1.10 is used
>>>>> c) The WAR file has been created using ant, namely its  
>>>>> MANIFEST.MF
>>>>> file is auto-created using ant
>>>>> d) The Eclipse 3.1 built-in ant is used (version 1.6.5)
>>>>> e) "Parent" and "Child" are both actually located in packages  
>>>>> that
>>>>> are typically not considered being system packages (like
>>>>> "javax.*"); rather, they are located in different "org.*" packages
>>>>> f) Playing around with
>>>>> "WebApplicationContext.setClassLoaderJava2Compliant(true)" does
>>>>> not  help
>>>>> g) Playing around with "WebApplicationContext.setExtractWAR  
>>>>> (true)"
>>>>> does not help, either
>>>>>
>>>>>
>>>>> WTH do I miss out here?
>>>>>
>>>>> Thanks for any help,
>>>>> Michel
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by xPML, a groundbreaking  
>>>>> scripting
>>>>> language
>>>>> that extends applications into web and mobile media. Attend the
>>>>> live webcast
>>>>> and join the prime developer group breaking into this new coding
>>>>> territory!
>>>>> http://sel.as-us.falkag.net/sel?
>>>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>> _______________________________________________
>>>>> Jetty-support mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>> language
>>>> that extends applications into web and mobile media. Attend the  
>>>> live
>>>> webcast
>>>> and join the prime developer group breaking into this new coding
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?
>>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>>> _______________________________________________
>>>> Jetty-support mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>> language
>>> that extends applications into web and mobile media. Attend the  
>>> live
>>> webcast
>>> and join the prime developer group breaking into this new coding
>>> territory!
>>> http://sel.as-us.falkag.net/sel?  
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Jetty-support mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>
>



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: WAR classloading problem

Greg Wilkins-5
Michel Drescher wrote:

> Hi Greg,
>
> On 28 Feb 2006, at 20:29, Greg Wilkins wrote:
>
>>
>> Well Michel,
>>
>> I'm open to considering changing the default....
>>
>> but I do take a little objection to the shouting of bug bug bug!
>>
>> The (IMHO stupid) inverted class loading behaviour of servlet  containers
>> is not a MUST, rather a recommendation:
>>
>>  "It is recommended also that the application class loader be
>> implemented so
>>   that classes and resources packaged within the WAR are loaded in
>> preference to
>>   classes and resources residing in container-wide library JARs."
>
>
> Fair enough. Though it was a requirement. BTW, I indeed think it is
> necessary as web applications should be as self-contained as  possible.
> Think of two web applications that must be hosted on the  same
> container, but both are written so that they require two  different
> versions of the same library which are totally incompatible  to each
> other. Th only solution is that each web application uses its  own
> packaged version of that library.


Here I disagree!  Strongly!

The real solution is that applications are developed against APIs not
against implementations.  

An app should depend on javax.xml  not xercesImpl-1.2.6.jar

Implementations of these APIs should be developed in a way that supports
backward compatibility - so that if the container just provides the
more recent implementation needed by any app, then all applications
should be happy.

If there is no standard API, then it does not need to be in the parent
scope classloader and then each webapp can have it's own version without
needing to invert the classloading hierarchy.


But having said that, if you do get a test web app that shows
some repeatable strangeness - please do send it in as there is
always more we can do to work around the issues cause by
this hierarchy problem.   I suspect that you might have two
versions of the jar, one in the parent and one in the webapp.


cheers




















-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Re: WAR classloading problem

Michel Drescher

On 7 Mar 2006, at 15:23, Greg Wilkins wrote:

> Michel Drescher wrote:
>> Hi Greg,
>>
>> On 28 Feb 2006, at 20:29, Greg Wilkins wrote:
>>
>>>
>>> Well Michel,
>>>
>>> I'm open to considering changing the default....
>>>
>>> but I do take a little objection to the shouting of bug bug bug!
>>>
>>> The (IMHO stupid) inverted class loading behaviour of servlet  
>>> containers
>>> is not a MUST, rather a recommendation:
>>>
>>>  "It is recommended also that the application class loader be
>>> implemented so
>>>   that classes and resources packaged within the WAR are loaded in
>>> preference to
>>>   classes and resources residing in container-wide library JARs."
>>
>>
>> Fair enough. Though it was a requirement. BTW, I indeed think it is
>> necessary as web applications should be as self-contained as  
>> possible.
>> Think of two web applications that must be hosted on the  same
>> container, but both are written so that they require two  different
>> versions of the same library which are totally incompatible  to each
>> other. Th only solution is that each web application uses its  own
>> packaged version of that library.
>
>
> Here I disagree!  Strongly!
>
> The real solution is that applications are developed against APIs not
> against implementations.
>
> An app should depend on javax.xml  not xercesImpl-1.2.6.jar

In general - in an ideal world - yes, I do agree.

In real life - well people to make mistakes, so we have to deal with  
this.

> Implementations of these APIs should be developed in a way that  
> supports
> backward compatibility - so that if the container just provides the
> more recent implementation needed by any app, then all applications
> should be happy.

As above, this is the ideal situation. No one can strictly ensure that.

> If there is no standard API, then it does not need to be in the parent
> scope classloader and then each webapp can have it's own version  
> without
> needing to invert the classloading hierarchy.

Think the other way round, as the servlet spec suggests:

The suggested model is that web app container providers advertise  
their container, with a list of supported modules (i.e.  
xercesImpl.jar, version 1.2.6).

Web app deployers then package the web app accordingly, referring to  
xercesImpl.jar in MANIFEST.MF and everybody is happy.

Now, consider there is a web app that needs xercesImpl.jar in a  
different version than the one provided container-globally and these  
different versions happen to be totally incompatible to each other.  
(Remember, this is the real world where people do make mistakes). The  
only way to escape the hassle known as "dll hell" is to allow the web  
app to override the container's classpath with its own shipped  
versions of a library, without forcing not only the container  
provider to upgrade the library, but also all other deployed web apps  
to do the same - this is simply not acceptable.

Note that, in a similar manner Linux distributions do the same by  
providing different versions of a library in different versions, i.e.  
glibc; they only use different names - J2EE uses different class  
loaders.

> But having said that, if you do get a test web app that shows
> some repeatable strangeness - please do send it in as there is
> always more we can do to work around the issues cause by
> this hierarchy problem.   I suspect that you might have two
> versions of the jar, one in the parent and one in the webapp.

Honestly, I don't know anymore. Could be a problem that showed up  
together with Eclipse, but I remember it showed up also when manually  
executing it. When I stumble upon that glitch again, I'll post it to  
the ML.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support