Paul Glezen wrote:
>
> Ceki Gülcü wrote:
> >
>
> > Tomcat 3.x does not use log4j. However, as far as I know, Tomcat 4.0, or more
>precisely Catalina, the Servlet container for Servlet API Specification 2.3, has
>opted to use log4j internally. I'll double check this shortly.
> >
> > The Tomcat API provides hooks to use different logging package then the one
>provided by tomcat internally. I have not used this extension facility extensions
>myself. However, I intend to study it in the near future.
> >
>
> I'm not so sure that Tomcat (or any other kind of app server) using
> log4j is a good thing. It was this very situation that got me to
> investigate log4j in the first place. I was using IBM's Component
> Broker which uses JRAS (an ancient version of IBM's JLOG). At first I
> was happy that I was getting a log package for free. JRAS was there by
> virtue of my app running in Component Broker.
>
> But as new versions of JRAS came out, I realized I couldn't use them
> without risking an incompatibility with Component Broker (which relied
> on an earlier version). I was essentially stuck with whatever version
> my appserver was using. Since logging tools tend to release more often
> than app servers, this significantly compromised the logging
> effectiveness. By using a tool like log4j that is not part of the app
> server, I can choose to upgrade (or choose not to) whenever I want. I
> can also tweak the code for certain specific needs without having to
> worry about impact to the app server.
My understanding is that servlet API 2.3 addresses this issue by saying
that app class loaders NOT delegate class loading to the parent. The
following quote is from an article discussing changes in 2.3:
http://www.javaworld.com/javaworld/jw-01-2001/jw-0126-servletapi_p.html
<quote>
Class loaders
Here's a small change with a big impact: In API 2.3, a servlet container
a.k.a. the server) will ensure that classes in a Web application not be
allowed to see the server's implementation classes. In other words, the
class loaders should be kept separate.
That doesn't sound like much, but it eliminates the possibility of a
collision between Web application classes and server classes. That had
become a serious problem because of XML parser conflicts. Each server
needs an XML parser to parse web.xml files, and many Web applications
these days also use an XML parser to handle reading, manipulation, and
writing of XML data. If the parsers supported different DOM or SAX
versions, that could cause an irreparable conflict. The separation of
class scope solves this issue nicely.
</quote>
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
