Re: can log4j.properties be loaded by a server rather than app class loader by default?

[Jacob Kjome <ho...@visi.com>]

At 11:19 AM 1/12/2007, you wrote:
 >Jacob Kjome <hoju <at> visi.com> writes:
 >> <quote>
 >>
 >getClass().getClassLoader().getResource("WEB-INF/config/my_log4j.properties");
 >> </quote>
 >>
 >> The above is totally invalid because the "WEB-INF" directory is not
 >(normally)
 >> in the classpath.
 >Well, it raised my brows too, i guess somehow it is in the classpath,
 >because it
 >works even in my from-scratch workspace.

Well, don't count on this behavior.  It is totally non-standard and 
will fail in most J2EE server environments.

 >> ...and Tomcat's classloading is implemented by Tomcat.  Please read up on
 >> Tomcat's classloading behavior before asking any more questions 
about this.
 >> Tomcat inverts the classloader delegation to use child-first, or 
parent-last,
 >> classloading behavior.  Well, it does that initially.  Once it 
can't find the
 >> resource locally, then it reverts back to normal parent-first delegation.
 >I misspoke, i meant whether log4j didn't rely on ClassLoader.getResource, and
 >somehow gave a preference to the archive the resource is loaded from. But how
 >can it determine the location of the archive on the filesystem for J2SE apps?

Log4j's autoconfiguration looks up "log4j.xml" and "log4j.properties" 
in the root of the classpath.  The first one the classloader finds 
for it is used (with log4j.xml being searched for first and 
log4j.properties second).  It's up to the classloader to find the 
resource.  Log4j has no say about where the classloader chooses to 
load the resource from.  Note that, after the fact, one can determine 
where the resource was loaded from by looking at the result of 
getResource("log4j.xml").toExternalForm().  But there's no way to 
tell the classloader to load it from a specific jar or specific 
directory beforehand.

 >
 >On the other hand, WebSphere 6 has a setting of PARENT LAST vs. PARENT first,
 >and a WAR Classloader Policy of WAR vs. Application.

Yep, and Tomcat implements PARENT_LAST for it's webapps by default, 
though it may be different when Tomcat is used as the servlet 
container for a Full J2EE stack such as JBOSS.  When I talk about 
Tomcat's behavior, I mean in Standalone mode, not used as an embedded 
servlet container.

 > >class.getClassLoader.getResource("com/mypackage/myresources/myResour
 >ce.properties");
 >Yes, i was just trying to determine if it was safe to make 
resources easier to
 >find but not namespacing them when they are module-specific. So 
far, it appears
 >that is only safe when ServletContext.getResource is used.
 >

That's the only guaranteed way, though Log4j autoconfiguration 
mechanism will still attempt to configure Log4j as soon as the 
LogManager class is loaded up, which will probably happen before your 
servlet context listener gets called, as it occurs in a static block 
inside LogManger.  There's a system property option to turn off 
autoconfiguration, but its on by default (something like 
-Dlog4j.autoconfigure=false, but you'll have to verify whether that's 
the correct system property name).

 >Thanks.


Jake


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org