tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Moore" <tmo...@blackboard.com>
Subject RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
Date Fri, 24 Jan 2003 16:00:15 GMT
> -----Original Message-----
> From: Cox, Charlie [mailto:ccox@cincom.com] 
> Sent: Friday, January 24, 2003 10:35 AM
> To: 'Tomcat Users List'
> Subject: RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
> 
> 
> you would need to keep in mind the security ramifications of 
> such a change. you don't want someone to place any directory 
> of jars in the list to be loaded where they could be accessed 
> by any jsp dropped into a webapp.

I'm afraid I don't really understand the threat here.  How would that be
different than just putting the jars into the common/lib directory?

> There's also directory/file permissions to think about for 
> each external directory or jar to be maintained.

Well, in my case, all I really want to do is effectively move the
common/lib directory to a different location outside of the Tomcat
directory structure.  True that we would need to manage the permissions
of that directory, but they wouldn't be any different from the
permissions of tomcat/common/lib, or from the way they are set now, for
that matter.

Basically, all I'm saying is that it would be nice if you could
configure the location of the directories that the Tomcat class loaders
currently have hardcoded.  Other than that, I'm not looking for any
drastic changes.

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863



> 
> Charlie
> 
> > -----Original Message-----
> > From: Tim Moore [mailto:tmoore@blackboard.com]
> > Sent: Friday, January 24, 2003 10:28 AM
> > To: Tomcat Users List
> > Subject: RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
> > 
> > 
> > Hi, John,
> > 
> > Referring back to the class loader how-to, the classes on 
> your system 
> > classpath are loaded in the bootstrap loader.  Classes 
> higher in the 
> > hierarchy cannot access classes lower in the hierarchy.
> > 
> > I am in a very similar situation to you: we have classes that
> > are shared
> > between webapps and command line tools, that reside in a 
> > common, shared
> > location.  The compromise we've used is to include several of 
> > the Tomcat
> > JARs on the system classpath used to launch the Tomcat JVM.  
> > Personally,
> > I'm not particularly happy with this solution, as it makes classpath
> > maintainance troublesome, but it basically works.
> > 
> > It would be nice if Tomcat had a more flexible classloading
> > scheme that
> > could be customized for situations like ours.  I think that 
> eventually
> > I'll end up writing a custom bootstrap & classloader for Tomcat that
> > will allow for configurable library directories. Hopefully I'll be
> > allowed to submit it back to the project.
> > 
> > Good luck,
> > --
> > Tim Moore / Blackboard Inc. / Software Engineer
> > 1899 L Street, NW / 5th Floor / Washington, DC 20036
> > Phone 202-463-4860 ext. 258 / Fax 202-463-4863
> > 
> > 
> > > -----Original Message-----
> > > From: Lorenti, John [mailto:JLORENTI@dcjs.state.va.us]
> > > Sent: Friday, January 24, 2003 8:53 AM
> > > To: 'Tomcat Users List'
> > > Subject: RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
> > > 
> > > 
> > > Tim,
> > > Maybe what I've done is taboo :-(  I've placed the top level
> > > directory that has all of our custom Java classes (shared by 
> > > all applications on the
> > > machine) on the Tomcat classpath.  Tomcat is finding my 
> > > TestFilter class there (since I chose to leave the class 
> > > there instead of placing it under the context's 
> > > WEB-INF/classes directory) which in turn references 
> > > javax.servlet.Filter.  Since other applications besides those 
> > > within Tomcat are using the "common" code, I'd like to keep 
> > > it in one place outside of Tomcat's structure.  However, from 
> > > what you've mentioned, it seems that I may need to keep any 
> > > Tomcat/Servlet specific classes where Tomcat is expecting 
> > > them to reside and not depend upon the classpath.
> > > 
> > > If this is the case, do you think that a Tomcat-friendly
> > > solution would be to separate my classes into two disjoint 
> > > sets - one having anything related to servlets, and the other 
> > > containing my "common" (non-Servlet specific) classes?  The 
> > > first set would live under the context's WEB-INF hierarchy, 
> > > and the other set living on the classpath.  If this can work, 
> > > then maybe I can "have my cake and eat it too."
> > > 
> > > Is there a better/more preferred way to accomplish class
> > > sharing beyond Tomcat's purview?
> > > 
> > > Thank you.
> > > -John
> > > 
> > > -----Original Message-----
> > > From: Tim Moore [mailto:tmoore@blackboard.com]
> > > Sent: Thursday, January 23, 2003 4:02 PM
> > > To: Tomcat Users List
> > > Subject: RE: java.lang.NoClassDefFoundError: javax/servlet/Filter
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Lorenti, John [mailto:JLORENTI@dcjs.state.va.us]
> > > > Sent: Thursday, January 23, 2003 3:53 PM
> > > > To: 'Tomcat Users List'
> > > > Subject: RE: java.lang.NoClassDefFoundError: 
> javax/servlet/Filter
> > > > 
> > > > 
> > > > Hello all,
> > > > After *explicitly* placing the 
> > > > <TOMCAT_HOME>/common/lib/servlet.jar on the Tomcat 
> classpath the 
> > > > Filter class is found.  However it is my understanding 
> that Tomcat 
> > > > shouldn't require me to do this since all jars in that 
> directory 
> > > > are loaded by Tomcat (aren't they?).  This is an ugly 
> workaround, 
> > > > but I thought it an interesting anomaly to pass on. -John
> > > 
> > > Oh here's a thought I just had...is there a class trying to
> > > reference javax.servlet.Filter that was already explicitly on 
> > > the classpath?  The stuff in common/lib is higher up in the 
> > > classloader hierarchy than the stuff on the base classpath 
> > > is, so that might explain it.
> > > 
> > > Hopefully that made sense...
> > > --
> > > Tim Moore / Blackboard Inc. / Software Engineer
> > > 1899 L Street, NW / 5th Floor / Washington, DC 20036
> > > Phone 202-463-4860 ext. 258 / Fax 202-463-4863
> > > 
> > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Lorenti, John [mailto:JLORENTI@dcjs.state.va.us]
> > > > Sent: Thursday, January 23, 2003 2:26 PM
> > > > To: 'Tomcat Users List'
> > > > Subject: RE: java.lang.NoClassDefFoundError: 
> javax/servlet/Filter
> > > > 
> > > > 
> > > > Hi again,
> > > > This is the first install of Tomcat on this server 
> (done about a 
> > > > month ago), and it is not presently running any jsp 
> applications 
> > > > save the examples. I've set up a few contexts, but 
> they're empty 
> > > > right now (except for this TestFilter in the /ws context), so I 
> > > > suspect the install is pretty clean.
> > > > I too was curious about whether or not the servlet.jar was 
> > > > the correct version, so I listed the jar's table of contents 
> > > > and saw that the javax.servlet.Filter was present (so I'm 
> > > > guessing this is the 2.3 jar - dated 09/23/2002).
> > > > 
> > > > Thanks again for you input.
> > > > -John
> > > > 
> > > > -----Original Message-----
> > > > From: Shapira, Yoav [mailto:Yoav.Shapira@mpi.com]
> > > > Sent: Thursday, January 23, 2003 12:40 PM
> > > > To: Tomcat Users List
> > > > Subject: RE: java.lang.NoClassDefFoundError: 
> javax/servlet/Filter
> > > > 
> > > > 
> > > > Howdy,
> > > > 
> > > > >Do you have any other thoughts?
> > > > 
> > > > I have many thoughts ;)  Most of which don't relate to your 
> > > > question unfortunately.
> > > > 
> > > > Is there any possibility unpacked classes from the 
> servlet.jar are 
> > > > scattered throughout your installation?  Or that the 
> servlet.jar 
> > > > file in your installation is NOT the version 2.3 jar?  Doing a 
> > > > clean installation of tomcat in a different directory may help 
> > > > solve this.
> > > > 
> > > > Yoav Shapira
> > > > Millennium ChemInformatics
> > 
> > --
> > To unsubscribe, e-mail:   
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:tomcat-user-help@jakarta.apache.org>
> 
> --
> To 
> unsubscribe, e-mail:   
> <mailto:tomcat-user-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> 
> 

--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message