Log4j configuration on Initialisation

[Jem Mawson <je...@loftinspace.com.au>]

Hello

I note that the Init class performs Log4j configuration using the
config.xml from within the xml-security.jar. This has the unfortunate
side-effect of removing any Log4j configuration that may have been set
from the application context.

Is it possible to avoid using the configurator if the rootlogger is
already configured with appenders? Or should the Log4j configuration only
occur in the test classes and be omitted from the xml-security library
proper?

Cheers
Jem

Re: Log4j configuration on Initialisation

[Berin Lautenbach <be...@wingsofhermes.org>]

Jem,

I just had a quick look at this.  I'd forgotten that Axl migrated all 
the logging to the commons-logging wrapper API some time back.

So 1.1 simply calls on commons logging objects, and the library does no 
configuration of any logging whatsoever.  Whatever you set up with log4j 
should work with v1.1 of the library.

(Note that 1.1 isn't strictly speaking released, but if you want to see 
what it should look like, have a look at 
http://xml.apache.org/security/1.1/ but note that it *may* change prior 
to public release, as it hasn't been fully reviewed yet.)

Cheers,
	Berin

Jem Mawson wrote:

> Hello
> 
> I note that the Init class performs Log4j configuration using the
> config.xml from within the xml-security.jar. This has the unfortunate
> side-effect of removing any Log4j configuration that may have been set
> from the application context.
> 
> Is it possible to avoid using the configurator if the rootlogger is
> already configured with appenders? Or should the Log4j configuration only
> occur in the test classes and be omitted from the xml-security library
> proper?
> 
> Cheers
> Jem
> 
> 
> 

Re: Log4j configuration on Initialisation

[trebor iksrazal <ik...@yahoo.com>]

--- Jem Mawson <je...@loftinspace.com.au> wrote:
> Thanks iksrazal
> 
> So you've reversed the problem by calling Init prior
> to initialising the
> correct configurator, thereby overwriting the
> xml-security configuration
> with your own. Is this right?

More or less. I prefer to do the xml-security Init via
servlets on startup also, so its guaranteed to happen
and its only done once. So far its worked well. 

But again, from my understanding this works cuz the
jars are loaded first, Init hasn't been called yet, my
init servlet loads the log config and then finally
calls xmlsec Init. 

This works for tomcat - whose classloader works that
way - but you may have to be careful for something
like Websphere whose classloader sequence is
configuarable. In the end Log4j is a singleton and
therefore only unique per jvm.

> 
> I still have my doubts about the xml-security
> library requiring its own
> log4j configuration. Can anyone confirm the
> requirement?
> 

I can guess and say that the xml-security project has
their own unit testing that needs logging, the scope
is really independant of things like axis and servlet
containers, and just about every apache project that
produces jars also has log4j config files. So its up
to you to use your own config. IMHO. 

HTH,
iksrazal

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

Re: Log4j configuration on Initialisation

[Jem Mawson <je...@loftinspace.com.au>]

Thanks iksrazal

So you've reversed the problem by calling Init prior to initialising the
correct configurator, thereby overwriting the xml-security configuration
with your own. Is this right?

I still have my doubts about the xml-security library requiring its own
log4j configuration. Can anyone confirm the requirement?

Cheers
Jem






> My solution - which incidently increased the
> performance dramatically - was to change the default
> level to warn and intialize log4j via
> PropertyConfigurator and a servlet on startup. The
> config file is read via getResourceAsStream out of
> WEB-INF/somedir . That allowed a custom config -
> catches all the axis stuff etc as well.
>
> The classloader sequence should load jars first, then
> allowing an overwrite by a servlet on via load on
> startup.
>
> As an aside, I use logging from
> http://protomatter.sourceforge.net/ for my app logging
> to avoid problems like these.
>
> HTH,
> iksrazal
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business $15K Web Design Giveaway
> http://promotions.yahoo.com/design_giveaway/
>

Re: Log4j configuration on Initialisation

[trebor iksrazal <ik...@yahoo.com>]

--- Jem Mawson <je...@loftinspace.com.au> wrote:
> Hello
> 
> I note that the Init class performs Log4j
> configuration using the
> config.xml from within the xml-security.jar. This
> has the unfortunate
> side-effect of removing any Log4j configuration that
> may have been set
> from the application context.
> 
> Is it possible to avoid using the configurator if
> the rootlogger is
> already configured with appenders? Or should the
> Log4j configuration only
> occur in the test classes and be omitted from the
> xml-security library
> proper?
> 
> Cheers
> Jem
> 

My solution - which incidently increased the
performance dramatically - was to change the default
level to warn and intialize log4j via
PropertyConfigurator and a servlet on startup. The
config file is read via getResourceAsStream out of
WEB-INF/somedir . That allowed a custom config -
catches all the axis stuff etc as well. 

The classloader sequence should load jars first, then
allowing an overwrite by a servlet on via load on
startup. 

As an aside, I use logging from
http://protomatter.sourceforge.net/ for my app logging
to avoid problems like these. 

HTH,
iksrazal


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/