Shibboleth Developers

[Chad La Joie <>]

Howard Gilbert wrote:
 > Tomcat has special support for Log4J. If there is a
> WEB-INF/classes/log4j.properties file in the WAR, it will parse it and
> establish a logging environment before running anything in the
> application. Rather than relying on this, the SP has been designed so
> that someone deploying the code can add their own
> WEB-INF/classes/log4j.properties file, and set up an environment that
> the SP inherits and adds to. Rather than depending on an external
> configuration file, the additional SP configuration is done by code in
> the ContextListener.

As I pointed out before this only guaranteed to work in the current
version of Tomcat because the firing of context listeners are not
placed, by spec, at any particular location within a servlet lifecycle
(other than they must occur before the servlet gets it's first request).
 This can lead to problems if you expect to be able to do logging in
things like the a servlet's init method.  A better method of doing this
is to create separate logging init mechanism.  You could either did what
I did with the IdP or create a special servlet that sets up logging (and
whatever else you might need) in it's init method and make sure that
servlet is started up first.

> The Java SP inherits from C++ a logger= attribute on the SPConfig main
> element of the configuration file. By the time this attribute is parsed,
> the XSD files have been compiled and some other initialization has been
> done. A decision had to be made what to do, and the current
> implementation treats the SPConfig logger= as an override. The previous
> logging hierarchy is completely replaced by a new hierarchy defined by
> this file.

How are you doing this?  Generally you can't destroy loggers one they're
created.  Usually the best you get is to update loggers that already
exist, or create new ones that are in your configuration but not already
created.

> This brings up the problem of JUnit tests. JUnit runs in its own
> environment and if logging has not been setup, then the first log.xxx()
> method encountered generates an error message on the console. Although
> one could manually set up logging with Java code as part of the test
> setup method, a simpler alternative is to add a log4j.properties file to
> the "tests" subdirectory of the java part of the shibboleth CVS tree
> where all the log4j tests reside.

A solution like the IdP logging init mechanism could deal with this.
You'd just read your config file like normal and initialize the logging
then.  Put this in the set up of SP test case and you should be set.

While on the subject of logging I am concerned about your usage of
thread local variables to store messages in the
e.i.m.commons.log4j.ThreadLocalAppender.  If some one were to accidently
use this in production and they had the logging level set to some
verbose level they could have memory issues under load.  This is because
threads (and hence thread local variables) are not always cleaned up
upon termination.  Their resources are reclaimed in a manner similar to
general object garbage collection so it's possible they could be sitting
around in memory for a while.  In theory the garbage collector would be
smart enough to reclaim this space if memory were getting low.  Just
something to be aware of.
-- 
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124