Hate to follow up on myself but my previous discussion is based on the
premise that log4j classes are loaded once and for all for everyone at JBoss
startup time. Playing class loader tricks à la Tomcat-Catalina makes it a
totally different game.
Am I correct to assume that log4j classes are loaded once and for all by
Jboss?
Regards, Ceki
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 26, 2001 10:07 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] jboss and log4j version 1.2
Hello Jason,
There is no firm release date for 1.2. It will be released when it is ready.
However, 1.2alpha0 is available since yesterday. :-)
Extending the interface of Logger (i.e. Category) with new printing methods
such as trace() is considered bad practice, at least by me. I understand
that adding printing methods is consistent with the rest of the API, easy on
the fingers and eyes. That is not good enough a reason. Log4j can never
guarantee that a given category will be of a certain type, say
org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger.
ClassCastException when instantiating a Category subclass is one example of
this problem.
See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce
In the future, I expect that Application Servers or Servlet Containers will
impose a particular org.apache.log4j.Logger implementation (for security
reasons). It will not be up to an embedded component to decide the logger
subclass. Thus, you will not be able to rely on a
org.jboss.logging.log4j.JBossCategory being returned even if you set the
categoryFactory to
org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the
configuration file.
Log4j support in JBoss is particularly important. I suggest that you look
into the
LogManager, RepositorySelector and LoggerRepository code. See also
http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718
The whole construction is intended to allow Application Servers to select
the appropriate LoggerRepository depending on the embedded application. Let
me give an example.
Assume we have to applications App-A and App-B running inside JBoss. We want
App-A and App-B to live in separate logging universes. We achieve this by
having App-A and App-B use different LoggerRepositories (LoggerRepository is
the new name for Hierarchies in log4j 1.2).
Clients still call Logger.getLogger("name") to retrieve a logger (=
category). However, we want to vary the LoggerRepository (~hierarchy)
depending on the caller. For a call to Logger.getLogger("name") emanating
from code in App-A, we want JBoss to detect that the caller is in App-A and
use the LoggerRepository specific to App-A. Similarly, calling
Logger.getLogger("name") within App-B should use a LoggerRepository specific
to App-B.
Since JBoss is the top-level application, JBoss is free to impose the
RepositorySelector to the LogManager. JBoss' implementation of
RepositorySelector can use different methods to track the caller (the
particular application), for example by setting a ThreadLocal variable to
track applications by Thread.
Regarding your last question, the DOMConfigurator offers more services than
ProppertyConfigurator and is considered as stable. Don't hesitate to
contact me if you encounter problems when migrating to the DOMConfigurator.
Regards, Ceki Gülcü
-----Original Message-----
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 25, 2001 11:10 PM
To: '[EMAIL PROTECTED]'
Subject: Re: [JBoss-dev] jboss and log4j version 1.2
> Hello,
Hi.
> There are a few changes in log4j 1.2 that require your attention.
Any clues to when 1.2 will be released?
> I also strongly recommend against sub-classing Logger (or Category) to
> introduce new printing methods, you can use the general purpose log method
> instead. For example,
> for some category-subclass object x instead of writing
> x.trace("hello")
> you can write
> x.log(SomePrioritySubclass.TRACE, "hello");
Why? The first is consistent with the other logging methods and it is
terse (easy on the eyes and fingers).
> If I am not mistaken, JBoss also uses deprecated and now removed methods
> such as getOptions/setOptions in its own appenders. There is no need for
> this as log4j uses introspection to configure its appenders and layouts.
I don't know anything about these, but we should fix that.
> Please let me know if you have any questions or comments. Regards, Ceki
Thanks for the update. Do you know if the xml config bits support all of
the features that the property based config does?
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
