Re: servlet.jar, /ext, MANIFEST.MF

[Patrick Luby]

Christopher,

There is an easier solution, although it has limits. Since the Tomcat binaries
include servlet.jar, we can put "-Djava.ext.dirs=" as an argument in the Tomcat
scripts. This argument causes the JVM to ignore any jars in its jre/lib/ext
directory so that there is no conflict between the jars shipped with your
application (Tomcat in this case) and the jars in your JVM's
jre/lib/ext directory. I think that this solution may also eliminate the vexing
problem where the JSSE jars are in jre/lib/ext as well.

Does this sound like a reasonable solution? If so, I can implement this in the
Tomcat scripts with minimal effort.

Patrick


"Christopher K. St. John" wrote:
> 
> The JDK documentation indicates that servlet.jar, as an
> official optional package, should be placed in the
> /lib/ext directory. [1] However, the Tomcat 4 documentation
> (well, the mailing list) indicates that servlet.jar should
> not be placed in /lib/ext. [2]
> 
> Catalina should be able to detect problems using
> java.lang.Package methods to query the version of the
> provided javax.servlet packages.
> 
>  It looks like this would require:
> 
>   1) jakara-servletapi-4 to provide a manifest with the
>  appropriate version information.
> 
>   2) Catalina to check the version information at some
>  point, perhaps optionally.
> 
> Is this a reasonable thing to do? I admit to a cosiderable
> amount of confusion over the balance between theory
> [3],[4],[5] and practice. Any feedback/clarification
> greatly appreciated.
> 
> [1] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html
>  4th paragraph of the Introduction uses servlet.jar as an
>  example of something that definitely belongs in /ext. I'm
>  not trying to argue about it, I'm just pointing out that
>  the documentation conflicts with common practice. I've
>  gotten into arguments with people who insist it's ok because
>  of the extensions spec says, specifically, that it is.
> 
> [2] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5523,
>  ref "Additional Comments", also:
>  http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg15098.html
>  ref para starting "TOMCAT-USER gets 10 or so messages a week".
> 
> [3] http://java.sun.com/products/jdk/1.2/docs/guide/extensions/spec.html
> 
> [4] 
>http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html
> 
> [5] SRV.9.7.1 "Dependencies On Extensions". Yes, I know,
> it isn't quite the same thing.
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

Patrick Luby wrote:
> 
> we can put "-Djava.ext.dirs=" as an argument in the Tomcat scripts.
> This argument causes the JVM to ignore any jars in its jre/lib/ext
> directory ...
> 

 But wouldn't that mean that "legitimate" exetensions were 
ignored? 


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Patrick Luby]

Christopher,

"Christopher K. St. John" wrote:
>  But wouldn't that mean that "legitimate" exetensions were
> ignored?
> 
Yes, they would be ignored. Although this is a limitation, it might be a
reasonable one when you consider all the potential problems that can be caused
by putting XML parsers, JSSE implementations, etc. that are different than the
ones that Tomcat expects in your jre/lib/ext directory.

Patrick


_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

Patrick Luby wrote: 
> "Christopher K. St. John" wrote:

> >  But wouldn't that mean that "legitimate" exetensions were
> > ignored?

> Yes, they would be ignored. 


 That seems a bit hostile. The majority of stuff that could
go into /ext is harmless. Ignoring it punishes users who
correctly install the "right" extensions. 

 My proposal was based on idea that if you can't solve a
hard-to-diagnose problem, you ought to at least make it
obvious. I'd be worried that ignoring /ext solves one
such problem but replaces it with another.

 jakarta-servletapi-4 packages ought to have version info
in any case. jakarta-tomcat-connector packages already do.
Is there a maintainer for the servletapi stuff?


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Patrick Luby]

Christopher,

"Christopher K. St. John" wrote:
>  That seems a bit hostile. The majority of stuff that could
> go into /ext is harmless. Ignoring it punishes users who
> correctly install the "right" extensions.

You have a good point. Using "-Djava.ext.dirs=" is an all or nothing approach
and may be too limiting.

>  My proposal was based on idea that if you can't solve a
> hard-to-diagnose problem, you ought to at least make it
> obvious. I'd be worried that ignoring /ext solves one
> such problem but replaces it with another.

I can't help but think that there might be a way to point Tomcat to its bundled
jars without losing access to any non-conflicting extensions. Since Tomcat
constructs its own class loader to load its bundled jars (including
servlet.jar), one possible solution would be to set the "-Djava.ext.dirs=" in
the scripts and then have the class loaders in Bootstrap.java add the jars in
the JVM's jre/lib/ext directory to the end of its search list. This way, any
conflicting extensions would be loaded after the bundled jars. We use a similar
mechanism to work around the endorsed dirs mechanism with JDK 1.4.

Does this seem to have potential? If it works, Tomcat would be able to isolate
itself from conflicting extensions (i.e. we could eliminate the problem instead
of just printing an error message) while still accessing the installed
extensions (e.g. JSSE, etc.).

Patrick

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Christopher K. St. John]

Patrick Luby wrote:
> 
> I can't help but think that there might be a way to point Tomcat
> to its bundled jars without losing access to any non-conflicting
> extensions.


 That would be better. (but the servletapi still should have
the appropriate version info :-)


> ... have the class loaders in Bootstrap.java add the jars in
> the JVM's jre/lib/ext directory to the end of its search list. 


 Hmm. To match the spec, I think there would need to be a new
classloader on top of all of those. Something like:

   ExtClassLoader (pithed)
   |
   AppClassLoader (as normal)
   |
  Catalina /ext   (new: loads /ext classes)
   |
Common(as normal)
  ...

 Which means that stuff loaded from the classpath won't have
access to extensions, so that's still not quite right. Since
Tomcat closely controls what's on the classpath I'm not sure
how much of an issues that is, but it's definitely a bit
different than normal.

 I'd settle for just having Tomcat print an error message if
there was a conflict, but if the classloader hacks can be
made to work that would obviously be better.

-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Patrick Luby]

Christopher,

Let me try this out later this week. I will let you know if the hack works.

Also, even if the hack does not check the version info of servlet.jar, I see
know harm in adding it.

Patrick

"Christopher K. St. John" wrote:
> 
> Patrick Luby wrote:
> >
> > I can't help but think that there might be a way to point Tomcat
> > to its bundled jars without losing access to any non-conflicting
> > extensions.
> 
>  That would be better. (but the servletapi still should have
> the appropriate version info :-)
> 
> > ... have the class loaders in Bootstrap.java add the jars in
> > the JVM's jre/lib/ext directory to the end of its search list.
> 
>  Hmm. To match the spec, I think there would need to be a new
> classloader on top of all of those. Something like:
> 
>ExtClassLoader (pithed)
>|
>AppClassLoader (as normal)
>|
>   Catalina /ext   (new: loads /ext classes)
>|
> Common(as normal)
>   ...
> 
>  Which means that stuff loaded from the classpath won't have
> access to extensions, so that's still not quite right. Since
> Tomcat closely controls what's on the classpath I'm not sure
> how much of an issues that is, but it's definitely a bit
> different than normal.
> 
>  I'd settle for just having Tomcat print an error message if
> there was a conflict, but if the classloader hacks can be
> made to work that would obviously be better.
> 
> --
> Christopher St. John [EMAIL PROTECTED]
> DistribuTopia http://www.distributopia.com
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

-- 
_
Patrick Luby  Email: [EMAIL PROTECTED]
Sun Microsystems  Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Patrick Luby]

Christopher,

I just committed the changes to the jakarta-tomcat-4.0 HEAD branch. Can 
you give it a try?

With these changes, Tomcat should load its own bundled jar and class 
files before any of the jar files in the JDK's installed extensions are 
loaded.

I tested this by putting servlet.jar in my JDK's jre/lib/ext directory 
and then inserted a broken version of the javax.servlet.http.HttpServlet 
  class (my broken version extended Object and had no methods) into the 
jar so that if the servlet.jar in the JDK's jre/lib/ext directory is 
used, Tomcat will throw tons of exceptions.

Let me know if you find any problems with my changes.

Thanks,

Patrick


Christopher K. St. John wrote:

> Patrick Luby wrote:
> 
>>I can't help but think that there might be a way to point Tomcat
>>to its bundled jars without losing access to any non-conflicting
>>extensions.
>>
> 
> 
>  That would be better. (but the servletapi still should have
> the appropriate version info :-)
> 
> 
> 
>>... have the class loaders in Bootstrap.java add the jars in
>>the JVM's jre/lib/ext directory to the end of its search list. 
>>
> 
> 
>  Hmm. To match the spec, I think there would need to be a new
> classloader on top of all of those. Something like:
> 
>ExtClassLoader (pithed)
>|
>AppClassLoader (as normal)
>|
>   Catalina /ext   (new: loads /ext classes)
>|
> Common(as normal)
>   ...
> 
>  Which means that stuff loaded from the classpath won't have
> access to extensions, so that's still not quite right. Since
> Tomcat closely controls what's on the classpath I'm not sure
> how much of an issues that is, but it's definitely a bit
> different than normal.
> 
>  I'd settle for just having Tomcat print an error message if
> there was a conflict, but if the classloader hacks can be
> made to work that would obviously be better.
> 
> 


-- 

Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet.jar, /ext, MANIFEST.MF

[Remy Maucherat]

> Christopher,
>
> I just committed the changes to the jakarta-tomcat-4.0 HEAD branch. Can
> you give it a try?
>
> With these changes, Tomcat should load its own bundled jar and class
> files before any of the jar files in the JDK's installed extensions are
> loaded.
>
> I tested this by putting servlet.jar in my JDK's jre/lib/ext directory
> and then inserted a broken version of the javax.servlet.http.HttpServlet
>   class (my broken version extended Object and had no methods) into the
> jar so that if the servlet.jar in the JDK's jre/lib/ext directory is
> used, Tomcat will throw tons of exceptions.

I get a classcast on JAXP with those changes on JDK 1.4 (fixed by removing
Xerces from endorsed).
Getting the CL to work right is tricky, and I'm not terribly interested in
supporting playing with the system extensions. So unless it is easy to fix,
I'm not sure it's a good idea to go through the whole debugging process for
the CL *again*.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: