You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/11/12 18:00:43 UTC
[logging] Resolving Logj4 issue
The Log4J issue on geronimo-dev@ brought out the suggestion that Log4J
(right place) or Commons Logging (expedient place) add TRACE level support
to the core code, thus relieving each app from having to do it.
I also suggest that geronimo-dev give serious consideration to adopting
Log4J v1.3, on the grounds that it will be the Release version long before
Geronimo is ready for Release, and Log4J has changes that effect this code
area.
If either of those things happen, I believe that the Log4J issue goes away.
Having said that, I leave it to the Log4J, Commons Logging, and Geronimo
Committers to resolve it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Resolving Logj4 issue
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 12 Nov 2003, at 20:24, Noel J. Bergman wrote:
>> From a Geronimo perspective, since commons-logging already has a trace
>> level, we could just trash any log4j code from Geronimo for now.
>
> The Commons Logging log4j adapter does TRACE at DEBUG right now because
> Log4J doesn't have a TRACE level. Dain suggested that we add an
> extended
> level for TRACE to Commons Logging. Others have said that they would
> like
> to see Log4J address it directly. Whatever solution comes from the
> discussion between the projects is probably fine. The important
> things are
> (a) improved collaboration, and (b) the solution.
commons-logging is now relied upon by a lot of projects. this means
that we have to be pretty conservative about changes. there are some
subtle choices concerning classloading which are required for
commons-logging to function correctly in servlet containers (such as
tomcat) but make it difficult to solve some other common user issues.
so, i'd probably advise against using using commons-logging directly.
i'd say that the basic commons logging interface (Log) is pretty much
optimal. the LogFactory interface is basically sound but the
implementation is over-complicated due to needs to allow independent
configurations for different context classloaders.
my personal recommendation would be that geronimo considers using the
extensive research done and experience gained by the commons-logging
team but uses a repackaged version with a modified LogFactory
implementation. this implementation should probably be configurable (by
JMX, say) rather than relying on the complex configuration mechanisms
employed by the commons-logging implementation.
this would isolate the container logging from issues with loggers in
contained application.
i would also recommend that a separate Log implementation be created
that extends Log4JLogger maps trace to a log4j level.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] Resolving Logj4 issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
> From a Geronimo perspective, since commons-logging already has a trace
> level, we could just trash any log4j code from Geronimo for now.
The Commons Logging log4j adapter does TRACE at DEBUG right now because
Log4J doesn't have a TRACE level. Dain suggested that we add an extended
level for TRACE to Commons Logging. Others have said that they would like
to see Log4J address it directly. Whatever solution comes from the
discussion between the projects is probably fine. The important things are
(a) improved collaboration, and (b) the solution.
--- Noel
RE: [logging] Resolving Logj4 issue
Posted by "Noel J. Bergman" <no...@devtech.com>.
> From a Geronimo perspective, since commons-logging already has a trace
> level, we could just trash any log4j code from Geronimo for now.
The Commons Logging log4j adapter does TRACE at DEBUG right now because
Log4J doesn't have a TRACE level. Dain suggested that we add an extended
level for TRACE to Commons Logging. Others have said that they would like
to see Log4J address it directly. Whatever solution comes from the
discussion between the projects is probably fine. The important things are
(a) improved collaboration, and (b) the solution.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] Resolving Logj4 issue
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, November 12, 2003, at 01:13 PM, James Strachan wrote:
> On 12 Nov 2003, at 17:00, Noel J. Bergman wrote:
>> The Log4J issue on geronimo-dev@ brought out the suggestion that Log4J
>> (right place) or Commons Logging (expedient place) add TRACE level
>> support
>> to the core code, thus relieving each app from having to do it.
>>
>> I also suggest that geronimo-dev give serious consideration to
>> adopting
>> Log4J v1.3, on the grounds that it will be the Release version long
>> before
>> Geronimo is ready for Release, and Log4J has changes that effect this
>> code
>> area.
>>
>> If either of those things happen, I believe that the Log4J issue goes
>> away.
>
> From a Geronimo perspective, since commons-logging already has a trace
> level, we could just trash any log4j code from Geronimo for now. Then
> when a log4j and commons-logging release comes out which supports
> trace level then we get the trace level code back again.
And so the virus claims another victim.
>
> Ceki will log4j 1.3 support trace level?
Oh Ceki, please, please, please, please, please...
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: [logging] Resolving Logj4 issue
Posted by James Strachan <ja...@yahoo.co.uk>.
On 12 Nov 2003, at 17:00, Noel J. Bergman wrote:
> The Log4J issue on geronimo-dev@ brought out the suggestion that Log4J
> (right place) or Commons Logging (expedient place) add TRACE level
> support
> to the core code, thus relieving each app from having to do it.
>
> I also suggest that geronimo-dev give serious consideration to adopting
> Log4J v1.3, on the grounds that it will be the Release version long
> before
> Geronimo is ready for Release, and Log4J has changes that effect this
> code
> area.
>
> If either of those things happen, I believe that the Log4J issue goes
> away.
From a Geronimo perspective, since commons-logging already has a trace
level, we could just trash any log4j code from Geronimo for now. Then
when a log4j and commons-logging release comes out which supports trace
level then we get the trace level code back again.
Ceki will log4j 1.3 support trace level?
James
-------
http://radio.weblogs.com/0112098/
Re: [logging] Resolving Logj4 issue
Posted by James Strachan <ja...@yahoo.co.uk>.
On 12 Nov 2003, at 17:00, Noel J. Bergman wrote:
> The Log4J issue on geronimo-dev@ brought out the suggestion that Log4J
> (right place) or Commons Logging (expedient place) add TRACE level
> support
> to the core code, thus relieving each app from having to do it.
>
> I also suggest that geronimo-dev give serious consideration to adopting
> Log4J v1.3, on the grounds that it will be the Release version long
> before
> Geronimo is ready for Release, and Log4J has changes that effect this
> code
> area.
>
> If either of those things happen, I believe that the Log4J issue goes
> away.
From a Geronimo perspective, since commons-logging already has a trace
level, we could just trash any log4j code from Geronimo for now. Then
when a log4j and commons-logging release comes out which supports trace
level then we get the trace level code back again.
Ceki will log4j 1.3 support trace level?
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org