logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: Reconsideration of features for 1.3 (Re: slf4j and log4j)
Date Wed, 04 May 2005 06:04:50 GMT
I agree that LoggingEvent should be serial-compatible with previous versions (1.2.7/8 at a
minimum).

If Chainsaw were to have its own release cycle, we would release a lot more often than log4j
and also plan releases to coincide with log4j's releases.

As discussed previously, at this point I'd prefer that Chainsaw stay as a part of the log4j
project -  primarily because the size of the developer community is not growing (it's been
2 with a few patches from others since it's inception).

I gave the 'category' -> 'logger' DTD example primarily to show how the DTD changed when
jdk 1.4 util.logging was released and log4j renamed major pieces of their system in order
to have names match.  There's no technical reason we couldn't support the prior DTD in XMLDecoder,
but I've only seen one person mention this bug and they were fine with updating their log4j
version to a more recent release in order to avoid the problem.

Scott







-----Original Message-----
From:	Curt Arnold [mailto:carnold@apache.org]
Sent:	Tue 5/3/2005 10:49 PM
To:	Log4J Developers List
Cc:	
Subject:	Re: Reconsideration of features for 1.3 (Re: slf4j and log4j)

On May 3, 2005, at 11:17 PM, Scott Deboy wrote:

> Chainsaw V2 has too many dependencies on new (1.3) features to be 
> incorporated into a 1.2.x release without major rework (relies on new 
> LoggingEvent constructors, receivers, etc.).  It's also available via 
> WebStart, so there is no real value in working to include it in a 
> 1.2.x release.
>
> Chainsaw can process events from any logging framework that can write 
> a file to disk in a fixed format (using LogFilePatternReceiver), can 
> read events out of a database, etc.  The only log4j 1.2.x-specific 
> capability is related to Chainsaw's ability to deserialize 
> LoggingEvents generated by older versions of SocketAppender.
>
> Chainsaw should be able to process files saved using 1.2.x XMLLayout - 
> Chainsaw expects 'logger' and not 'category' for the name of the 
> logger node, but this changed in Oct 2002.  Versions of log4j prior to 
> Oct 2002, which used XMLLayout to create files, would not be able to 
> be processed.
>
> Properties were the only feature added to the XML with log4j 1.3 (if I 
> remember correctly), and they are optional.
>

We left Chainsaw in a little bit of limbo with its own CVS module, but 
not as formal subproject of Logging Services.  I'm thinking that it 
might be best if Chainsaw had its own release cycle and would 
incorporate log4j classes in its jar file instead of assuming that it 
would be paired with a particular log4j.jar.  Assuming that we can get 
the serialized forms compatible, it shouldn't matter is your app using 
1.2.x is being monitored by Chainsaw or Chainsaw 2.

Is there any reason it would be difficult for Chainsaw to process both 
"logger" and "category" as equivalent in XML files?  I can take a look 
unless there is a reason not to.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org





Mime
View raw message