At 15:05 12.12.2002 -0600, Jacob Kjome wrote:
Hello Mark,
MW> I would also like to say that I have proposed that we include servlet/web
MW> application support in v1.3 of log4j. This would include an init servlet,
MW> context listeners, configuration via a servlet, etc. Jacob has proposed to
MW> include his servlet as a start (<hint>Maybe Jacob would like to lead the
MW> effort...</hint>). If anyone has other ideas/submissions, we'd like to hear
MW> about them. We want to make log4j as useful as possible "out of the box" so
MW> that folks don't have to re-invent the wheel each time.
+1
Actually, the main thing I'd propose is having Log4jCRS (Log4j
Contextual Repository Selector) be included with the Log4j
distribution. The reasons for this are described in my post that Mark
linked to above.
Currently, the way that Log4jCRS works, the classes
that are invoking it must be loaded via the WebappClassloader because
each logger repository is keyed on the classloader. So, including the
Log4jInit servlet and Log4jApplicationWatch SCL in log4j.jar would not
work because Log4j needs to have the flexibility to be in the
WebappClassloader or a parent classloader. The only requirement for
Log4jCRS is that it is in the same classloader as Log4j.jar so
including it there would be ideal. Right now in the Barracuda
project, we separate out Log4jCRS into its own jar which we move
around to wherever the log4j.jar exists. If log4j.jar exists in
WEB-INF/lib then the jar containing Log4jCRS *must* be there also. If
log4j.jar exists in a parent classloader (such as common/lib) then the
jar containing Log4jCRS *cannot* be in WEB-INF/lib because log4j won't
be able to load Log4jCRS because although the WebappClassloader can
see the parent classloaders, the converse is not true. Since Log4jCRS is registered as the
repostory selector (replacing the default one), log4j.jar must be able communicate with Log4jCRS.
Given this dependency, it make complete sense to include Log4jCRS in
log4j.jar.
Just to make sure I understand, Log4jCRS and log4j.jar must be mutually accessible. Thus, you have to put Log4jCRS.jar where log4j.jar is, and vice versa. Is that a problem apart from being cumbersome? Is there any other problem? (Again I am trying to make sure I understand correctly.)
Hopefully that was somewhat clear. Log4jInit and Log4jApplicationWatch need to be in a separate jar which is included in each app's WEB-INF/lib. I have added all the magic I can to make this work reasonably well. If Ceki or you (Mark) can figure out a way where Log4jCRS can work without Log4jInit and Log4jApplicationWatch existing in each app's WEB-INF/lib, then they can be included in the log4j.jar. Otherwise, I'd recommend building a second jar for them or including them as mere examples for how to configure log4 in a webapp, but not include them in the core of Log4j (ie, don't include them in log4j.jar). So, Ceki, Mark, do you have any ideas for improving upon the flexibility of Log4jCRS? If you provide the suggestions, I'll definitely try to implement those suggestions and drive this thing as you were hoping. However, I'll need some code review to let me know where things could be more optimized, made more flexible, and conform to the standards of the classes included in Log4j.
The classloader based approach has one severe limitation. Without explicit Container support, it kinda breaks down for applications with multiple classloaders. For example, in an EJB applicaiton, beans have their own classloader, web-applications have another class loader, and JSPs have yet another even if they all live in the same application (EAR file). See the problem? By the way, do JSPs and servlets share the same class loader in Tomcat? (I am too lazy too find out.) One possible one-shot-kill-all-birds solution is to use the JNDI space. See the updated version of http://www.qos.ch/logging/sc.html (in particular JNDIRS). What do you think? I also suggested the JNDI solution in commons-dev in a somewhat different context. It seemed to be well received. See: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103960105431093&w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103963024331315&w=2 http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103966907603362&w=2 -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
