Stuart Thomson wrote:
> "Craig R. McClanahan" wrote:
> >
> > Stuart Thomson wrote:
> >
> > > > 3) The new class loader scheme in this release ignores your CLASSPATH setting.
> > > > Instead, you are expected to add needed jars to Tomcat's "lib",
>"lib/common",
> > > > and "lib/shared" directories. See the "README" file in Tomcat's "doc"
> > > > directory for details.
> > >
> > > This will probably stop me from ever going to Tomcat 3.3. Finding
> > > classes on the classpath is very convenient at development time.
> > >
> >
> > You will find that Tomcat 4.0 has a similar restriction -- the CLASSPATH
>environment
> > variable passed in to tomcat.bat or tomcat.sh is totally ignored, and any user
>JARs in
> > the "lib" directory are automatically made available to all web applications.
> >
> > Experience has shown that CLASSPATH problems account for nearly all newbie problems
> > other than the ones related to mod_jk or mod_jserv (that means well over half the
> > problem reports are related to this). Having a clear policy on what is included
>makes
> > life much simpler for newcomers (who don't always understand what a CLASSPATH
>really
> > does) to get set up.
> >
> > People who know they want to include other things are also free to modify the
>standard
> > startup scripts -- but they are also expected to know enough to keep themselves
>out of
> > trouble.
> >
> > Craig McClanahan
>
> I can see the logic in ignoring the classpath in a deployment
> environment. I also welcome the idea that servlets will not have access
> to the implementation classes of the container. Although making classes
> in the lib directory available to all could be a problem, what if a
> servlet has e.g. it's own version of xerces in the war file. Will the
> war file jars or the tomcat/lib jars take precedence ?
>
For Tomcat 4.0, classes are loaded in the following priority order:
* WEB-INF/classes
* WEB-INF/lib/*.jar
* $CATALINA_HOME/lib
in other words, classes in your web app *will* override classes of the same name
loaded from
the shared repositories. This is true for XML parsers, JDBC drivers, or anything else.
NOTE: Up until yesterday, there were problems with trying to override the JAXP 1.1
parser
(used by the JSP page compiler), due to the fact that "jaxp.jar" and "crimson.jar" are
marked sealed. This has been worked around as of last night's nightly build, so
applications that want to use Xerces (by putting xerces.jar in WEB-INF/lib of the web
app)
will no longer encounter "package sealing violation" exceptions.
> Stuart
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
