> 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. :-)
Is there any compelling reason why we should switch to this alpha? I am all
for the new API, but I am very weary of alpha/beta product.
> 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
I see your point here, but the suggested usage for implementing trace() is
just plain ugly. I would still suggest that we use our own Logger class
which has all of the features and niceness which we desire, but uses Log4j
as the underlying mechanism.
I have been playing with logging systems for several years now, and I am
coming to the conclusion that there is no single perfect logging api for
application use. I am starting to think that each platform (like JBoss)
should provide it's own interface, but leave the details of event
management, configuration and the like, to a package like Log4j.
I have not looked into the new LogManager and related classes yet, but I am
glad to see things moving in this direction. I can totally see that I might
want to completly disable logging via a NullLogger for some components,
where I might want full thread dumps from others. Having one class handle
both of these extremes will slow things down.
Anyways, I would suggest that JBoss alter Logger to extend Object and make
it a thin proxy to a Log4j logger. This way we don't have to worry about
any class cast issues, and we can have a trace(), plus other features.
> 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.
As I mentioned before, I would still expect our core components and plugins
to use the JBoss Logger.create() methods to get an instance of a Logger.
> 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
Logging in an application server and the applications which run in it is
very, very important. I have been playing with my own Bliss planet57.log
api for a while now, but have finally concieded the backed to Log4j, since
you do it much better than I could hope to given the time I have to work on
it.
> 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.
Sounds very, very interesting. I will have to look into this more.
> 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.
Thanks,
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
