JBAS-2112 - nlog4j

[adrian.brock]

This is the discussion thread for this patch/feature request:
http://jira.jboss.com/jira/browse/JBAS-2112

My vote would be NO in JBoss4 (for now) for the following reasons:

* It firsts need proving to be stable in the jboss-head/jboss5 branch

Logging is a critical part of JBoss and given the problems we have had
in the past with log4j and commons-logging (some of our own making)
we should not just replace this without an extra "due diligence" and stress testing.

* Removal of deprecated classes

Although we can fix our classes there are *many* deployments out there that
rely on JBoss providing the log4j api.

BTW: I guess, sooner or later slf4j (http://slf4j.org/) will be used by all major projects ...

It might be true that JBoss using slf4j will speed the adoption of that project,
but it will also slow the adoption of new JBoss releases if it breaks
existing applications.

[adrian.brock]

And we still have some minor issues that might have been caused by
previous upgrades of log4j
http://jira.jboss.com/jira/browse/JBAS-1851

e.g. This does not (no longer?) works

 <appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender">
 <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
 <param name="Facility" value="LOCAL7"/>
 <param name="FacilityPrinting" value="true"/>
 <param name="SyslogHost" value="localhost"/>
 </appender>

It is missing mandatory configuration that causes an NPE.

[elkner]

e.g. This does not (no longer?) works

<appender .../>

It is missing mandatory configuration that causes an NPE.

Yes, it needs a layout section. But this is an issue for the already used log4j-1.2.8.jar as well.

[adrian.brock]

"elkner" wrote:
Yes, it needs a layout section. But this is an issue for the already used log4j-1.2.8.jar as well.

Yes it is. But my point was that it might have been broken by a previous upgrade
I didn't investigate whether this worked at any point in the past?

We only have it is an example, but somebody else will have been using it,
so we broke their config.

P.S. It would be good if it gave a more meaningful error message than NPE. ;-P

[elkner]

It might be true that JBoss using slf4j will speed the adoption of that project, but it will also slow the adoption of new JBoss releases if it breaks existing applications.

Yepp, and that's why I think nlog4j is well suited for this case - backward compat with log4j (so old stuff can still use log4j) and new apps can already start using the new API ...