RSSAppender contribution

[sdeboy]

Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome dependencies).

I asked her if she'd be willing to contribute the appender to the log4j project, and she was happy to.

She's modified the source to be java 1.3 compatible and has included a couple of tests as well. 

If there are any issues or concerns, let's discuss them.  Otherwise, I'd like to commit the appender to an RSS directory, and probably include it in the log4j-xml.jar target.

Scott

[Jacob Kjome]

Quoting Scott Deboy <sdeboy@...>:

> Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome
> dependencies).
>

How dependent on JDOM is it (and what is "rome"?  Did you mean "some"?  If so,
what are the other dependencies?)?  Can it be changed to basic DOM or SAX in
order to get rid of the JDOM dependency?  I can see application code depending
on JDOM, especially since then it is the individual developer's choice, but we
should avoid these dependencies if at all possible in utility code such as
Log4j.

Otherwise, I welcome the contribution.

Jake

> I asked her if she'd be willing to contribute the appender to the log4j
> project, and she was happy to.
>
> She's modified the source to be java 1.3 compatible and has included a couple
> of tests as well.
>
> If there are any issues or concerns, let's discuss them.  Otherwise, I'd like
> to commit the appender to an RSS directory, and probably include it in the
> log4j-xml.jar target.
>
> Scott
>

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

[sdeboy]

Rome is an RSS API (ASL) - https://rome.dev.java.net/

It looks like JDOM is only used to pretty-print (indenting, line separator) the resulting xml.

I'll email her and see if she doesn't mind removing the dependency.

Scott


-----Original Message-----
From: Jacob Kjome [mailto:hoju@...]
Sent: Mon 11/28/2005 9:06 AM
To: Log4J Developers List
Subject: Re: RSSAppender contribution
 
Quoting Scott Deboy <sdeboy@...>:

> Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome
> dependencies).
>

How dependent on JDOM is it (and what is "rome"?  Did you mean "some"?  If so,
what are the other dependencies?)?  Can it be changed to basic DOM or SAX in
order to get rid of the JDOM dependency?  I can see application code depending
on JDOM, especially since then it is the individual developer's choice, but we
should avoid these dependencies if at all possible in utility code such as
Log4j.

Otherwise, I welcome the contribution.

Jake

> I asked her if she'd be willing to contribute the appender to the log4j
> project, and she was happy to.
>
> She's modified the source to be java 1.3 compatible and has included a couple
> of tests as well.
>
> If there are any issues or concerns, let's discuss them.  Otherwise, I'd like
> to commit the appender to an RSS directory, and probably include it in the
> log4j-xml.jar target.
>
> Scott
>

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




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

[Jacob Kjome]

Quoting Scott Deboy <sdeboy@...>:

> Rome is an RSS API (ASL) - https://rome.dev.java.net/
>

Oh, I see.  Yes, that's a pretty necessary dependency in this case :-)

> It looks like JDOM is only used to pretty-print (indenting, line separator)
> the resulting xml.
>
> I'll email her and see if she doesn't mind removing the dependency.
>

Cool

Jake

> Scott
>
>
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@...]
> Sent: Mon 11/28/2005 9:06 AM
> To: Log4J Developers List
> Subject: Re: RSSAppender contribution
>
> Quoting Scott Deboy <sdeboy@...>:
>
> > Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome
> > dependencies).
> >
>
> How dependent on JDOM is it (and what is "rome"?  Did you mean "some"?  If
> so,
> what are the other dependencies?)?  Can it be changed to basic DOM or SAX in
> order to get rid of the JDOM dependency?  I can see application code
> depending
> on JDOM, especially since then it is the individual developer's choice, but
> we
> should avoid these dependencies if at all possible in utility code such as
> Log4j.
>
> Otherwise, I welcome the contribution.
>
> Jake
>
> > I asked her if she'd be willing to contribute the appender to the log4j
> > project, and she was happy to.
> >
> > She's modified the source to be java 1.3 compatible and has included a
> couple
> > of tests as well.
> >
> > If there are any issues or concerns, let's discuss them.  Otherwise, I'd
> like
> > to commit the appender to an RSS directory, and probably include it in the
> > log4j-xml.jar target.
> >
> > Scott
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@...
> For additional commands, e-mail: log4j-dev-help@...
>
>
>

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

[Jess Holle]

I just about a day and a half trying to get my code to be log4j 1.3 compatible while still being log4j 1.2.12+ compatible.  Note this was despite the fact that I reviewed the 1.3 compatibility guidelines prior to writing any of this code.  I clearly stepped over the lines in various areas, but there were non-trivial reasons for this.

I have to say I am shocked by the lack of compatibility between the two.  I understand the need to clean things up, but there were a lot of gratuitous incompatibilities.

Worst of all, despite all my efforts and the fact that my code now compiles just fine against 1.2.12+ and 1.3 alpha 7, I cannot compile against 1.2 and run with 1.3 (or presumably vice versa).  This turns out to be due to the fact that Logger has the following methods in log4j 1.2:

• isEnabledFor(Priority)
• log(Priority,Object)
• log(Priority,Object,Throwable)

whereas in log4j 1.3 there are only equivalents of this that take "Level" instead of Priority.  The only alternative here appears to be to introduce some reflection-based utility, but that would defeat the speed and efficiency of these calls whose performance is absolutely critical!

For this issue I would really like to see log4j 1.2.13 introduce:

• isEnabledFor(Level)
• log(Level,Object)
• log(Level,Object,Throwable)

Compilation against 1.2.13 would then automatically bind against these methods in preference to those above when passed Level objects, which should always be the case if one is following the 1.3 compatibility guidelines.  This would then produce binaries that are compatible with 1.2.13 and 1.3 -- assuming various source-level compatibility guidelines are followed.

I suspect there may be other such issues lingering elsewhere in the API but these methods are so widely used and so critical that they should  be addressed immediately and that may solve the problem for many.

Other compatibility issues (source-level, in these cases) beyond this that I encountered included:

• I had to use java.lang.reflect.Proxy to create code that would compile against log4j 1.2 or 1.3 unchanged but yet could listen for the addition of an appender to a logger repository (i.e. I conditionally create either a LoggerEventListener proxy or a HierarchyEventListener proxy depending on what I can load).
• Was it really necessary to maroon all HierarchyEventListener's and break all code that adds them?
  
• By the way, neither log4j 1.2 nor 1.3 fire any event upon removing an appender from a logger, despite the API's implication that this will be done.  Also log4j 1.3 does not fire a level changed event despite implying that it does!  This issue should be addressed irrespective of compatibility-level decisions!
  
• In case my code ever gets a Category object in 1.2 I had to create a reflection-based wrapper to get the name of a Logger/Category object that will compile against both 1.2 and 1.3.
• The RepositorySelector interface now has 2 more methods.  This breaks all existing implementations of this interface!  Introducing these methods via a sub-interface and/or checking for them via reflection upon initial selector registration would have been preferable.
• org.apache.log4j.RollingFileAppender and org.apache.log4j.DailyRollingFileAppender are no longer subclasses of FileAppender and no longer provide get/setEncoding() methods.
  
• I understand that these classes are retained purely for compatibility, but:
• These changes unnecessarily break existing code.
• The replacement class is rather generic and is substantially harder to configure (neither the log4j MBeans nor my own enhanced replacements thereof handle this class yet -- nor does the properties configurator), so I see these classes as living a *lot* longer in practice -- at least DailyRollingFileAppender.
• In trying to produce truly generic MBean wrappers for 1.2 I had to special case Priority objects to convert to/from Strings and had to add reflection based logic to decide whether to use Priority or Level in such cases.
• Layout's setIgnoresThrowable() has no corresponding isIgnoresThrowable() or getIgnoresThrowable() so anything based on bean patterns (e.g. the log4j MBeans last I looked and mine as well) will not pick up on the fact that the 'ignoresThrowable' property is readable.  An isIgnoresThrowable() or getIgnoresThrowable() method should be introduced (it can simply call ignoresThrowable(), of course).

Such issues -- both binary and source compatibility, but especially the binary compatibility issues -- would seem to:

• limit log4j 1.3 migration,
• fragment the log4j community, and
  
• push log4j users towards any available alternative.

All of which are the last thing any of us want.

Is there any chance such issues can be addressed?  Is there any notion as to when log4j 1.3 might realistically be released?  I fear for the deadlocking issues in 1.2 and want to see a move to 1.3, but the number of hurdles above beyond simple "don't use Priority or Category in your source code" mantra would seem to hurt the log4j community if the 1.3 release was to occur today.  On the other hand assuming nothing else broke that I use that in turn uses log4j, I'd personally just recompile against 1.3 at that point.  I'm a bit doubtful that nothing else would break, however!

--
Jess Holle

[Jess Holle]

P.S. As log4j 1.3 now stands, I'd think it would be tempting to repackage all of log4j 1.3 in org.apache.log4j2.* and call it log4j 2.0.  That way you could have log4j 1.2 and 1.3/2.0 in the same classloader at the same time without having to worry about some legacy library that requires 1.2.x and some other than requires 1.3.x.  As it stands now I worry about such issues cropping up more often than not.

That's ugly, yes, but 1.3 seems to go out of its way to break both binary and source compatibility -- in which case using the same fully qualified package names is a bad thing!

Jess Holle wrote:

I just about a day and a half trying to get my code to be log4j 1.3 compatible while still being log4j 1.2.12+ compatible.  Note this was despite the fact that I reviewed the 1.3 compatibility guidelines prior to writing any of this code.  I clearly stepped over the lines in various areas, but there were non-trivial reasons for this.

I have to say I am shocked by the lack of compatibility between the two.  I understand the need to clean things up, but there were a lot of gratuitous incompatibilities.

Worst of all, despite all my efforts and the fact that my code now compiles just fine against 1.2.12+ and 1.3 alpha 7, I cannot compile against 1.2 and run with 1.3 (or presumably vice versa).  This turns out to be due to the fact that Logger has the following methods in log4j 1.2:

• isEnabledFor(Priority)
• log(Priority,Object)
• log(Priority,Object,Throwable)

whereas in log4j 1.3 there are only equivalents of this that take "Level" instead of Priority.  The only alternative here appears to be to introduce some reflection-based utility, but that would defeat the speed and efficiency of these calls whose performance is absolutely critical!

For this issue I would really like to see log4j 1.2.13 introduce:

• isEnabledFor(Level)
• log(Level,Object)
• log(Level,Object,Throwable)

Compilation against 1.2.13 would then automatically bind against these methods in preference to those above when passed Level objects, which should always be the case if one is following the 1.3 compatibility guidelines.  This would then produce binaries that are compatible with 1.2.13 and 1.3 -- assuming various source-level compatibility guidelines are followed.

I suspect there may be other such issues lingering elsewhere in the API but these methods are so widely used and so critical that they should  be addressed immediately and that may solve the problem for many.

Other compatibility issues (source-level, in these cases) beyond this that I encountered included:

• I had to use java.lang.reflect.Proxy to create code that would compile against log4j 1.2 or 1.3 unchanged but yet could listen for the addition of an appender to a logger repository (i.e. I conditionally create either a LoggerEventListener proxy or a HierarchyEventListener proxy depending on what I can load).
• Was it really necessary to maroon all HierarchyEventListener's and break all code that adds them?
  
• By the way, neither log4j 1.2 nor 1.3 fire any event upon removing an appender from a logger, despite the API's implication that this will be done.  Also log4j 1.3 does not fire a level changed event despite implying that it does!  This issue should be addressed irrespective of compatibility-level decisions!
  
• In case my code ever gets a Category object in 1.2 I had to create a reflection-based wrapper to get the name of a Logger/Category object that will compile against both 1.2 and 1.3.
• The RepositorySelector interface now has 2 more methods.  This breaks all existing implementations of this interface!  Introducing these methods via a sub-interface and/or checking for them via reflection upon initial selector registration would have been preferable.
• org.apache.log4j.RollingFileAppender and org.apache.log4j.DailyRollingFileAppender are no longer subclasses of FileAppender and no longer provide get/setEncoding() methods.
  
• I understand that these classes are retained purely for compatibility, but:
• These changes unnecessarily break existing code.
• The replacement class is rather generic and is substantially harder to configure (neither the log4j MBeans nor my own enhanced replacements thereof handle this class yet -- nor does the properties configurator), so I see these classes as living a *lot* longer in practice -- at least DailyRollingFileAppender.
• In trying to produce truly generic MBean wrappers for 1.2 I had to special case Priority objects to convert to/from Strings and had to add reflection based logic to decide whether to use Priority or Level in such cases.
• Layout's setIgnoresThrowable() has no corresponding isIgnoresThrowable() or getIgnoresThrowable() so anything based on bean patterns (e.g. the log4j MBeans last I looked and mine as well) will not pick up on the fact that the 'ignoresThrowable' property is readable.  An isIgnoresThrowable() or getIgnoresThrowable() method should be introduced (it can simply call ignoresThrowable(), of course).

Such issues -- both binary and source compatibility, but especially the binary compatibility issues -- would seem to:

• limit log4j 1.3 migration,
• fragment the log4j community, and
  
• push log4j users towards any available alternative.

All of which are the last thing any of us want.

Is there any chance such issues can be addressed?  Is there any notion as to when log4j 1.3 might realistically be released?  I fear for the deadlocking issues in 1.2 and want to see a move to 1.3, but the number of hurdles above beyond simple "don't use Priority or Category in your source code" mantra would seem to hurt the log4j community if the 1.3 release was to occur today.  On the other hand assuming nothing else broke that I use that in turn uses log4j, I'd personally just recompile against 1.3 at that point.  I'm a bit doubtful that nothing else would break, however!

--
Jess Holle

[Jess Holle]

Jess Holle wrote:

P.S. As log4j 1.3 now stands, I'd think it would be tempting to repackage all of log4j 1.3 in org.apache.log4j2.* and call it log4j 2.0.  That way you could have log4j 1.2 and 1.3/2.0 in the same classloader at the same time without having to worry about some legacy library that requires 1.2.x and some other than requires 1.3.x.  As it stands now I worry about such issues cropping up more often than not.

That's ugly, yes, but 1.3 seems to go out of its way to break both binary and source compatibility -- in which case using the same fully qualified package names is a bad thing!

Jess Holle wrote:

I just about a day and a half trying to get my code to be log4j 1.3 compatible while still being log4j 1.2.12+ compatible.  Note this was despite the fact that I reviewed the 1.3 compatibility guidelines prior to writing any of this code.  I clearly stepped over the lines in various areas, but there were non-trivial reasons for this.

I have to say I am shocked by the lack of compatibility between the two.  I understand the need to clean things up, but there were a lot of gratuitous incompatibilities.

Worst of all, despite all my efforts and the fact that my code now compiles just fine against 1.2.12+ and 1.3 alpha 7, I cannot compile against 1.2 and run with 1.3 (or presumably vice versa).  This turns out to be due to the fact that Logger has the following methods in log4j 1.2:

• isEnabledFor(Priority)
• log(Priority,Object)
• log(Priority,Object,Throwable)

whereas in log4j 1.3 there are only equivalents of this that take "Level" instead of Priority.  The only alternative here appears to be to introduce some reflection-based utility, but that would defeat the speed and efficiency of these calls whose performance is absolutely critical!

For this issue I would really like to see log4j 1.2.13 introduce:

• isEnabledFor(Level)
• log(Level,Object)
• log(Level,Object,Throwable)

Also give that most legacy libraries won't be recompiled against a hypothetical 1.2.13 real soon, there is still something to be said for either:

• Reintroducing Category and Priority
• Sure their existence is ugly but how much did they *really* hurt anyone?
• Repackaing log4j 1.3 under org.apache.log4j2.*

--
Jess Holle

[Jess Holle]

Another binary compatibility issue:

The 1.3 introduction of put(String,String) in MDC produces a binary that is incompatible with any log4j 1.2.x whenever the compiler knows the type of the second argument to be String (which is usually the case).

This can, of course, be avoided by casting such Strings to Object, but overall this is just another hurdle between 1.2 and 1.3 for ever so little benefit.  Adding a "setProperty" or "putString" method instead akin to java.util.Properties would allow new code to use a safer API without hurting binary compatibility of recompiled legacy sources.

--
Jess Holle

Jess Holle wrote:

Jess Holle wrote:

P.S. As log4j 1.3 now stands, I'd think it would be tempting to repackage all of log4j 1.3 in org.apache.log4j2.* and call it log4j 2.0.  That way you could have log4j 1.2 and 1.3/2.0 in the same classloader at the same time without having to worry about some legacy library that requires 1.2.x and some other than requires 1.3.x.  As it stands now I worry about such issues cropping up more often than not.

That's ugly, yes, but 1.3 seems to go out of its way to break both binary and source compatibility -- in which case using the same fully qualified package names is a bad thing!

Jess Holle wrote:

I just about a day and a half trying to get my code to be log4j 1.3 compatible while still being log4j 1.2.12+ compatible.  Note this was despite the fact that I reviewed the 1.3 compatibility guidelines prior to writing any of this code.  I clearly stepped over the lines in various areas, but there were non-trivial reasons for this.

I have to say I am shocked by the lack of compatibility between the two.  I understand the need to clean things up, but there were a lot of gratuitous incompatibilities.

Worst of all, despite all my efforts and the fact that my code now compiles just fine against 1.2.12+ and 1.3 alpha 7, I cannot compile against 1.2 and run with 1.3 (or presumably vice versa).  This turns out to be due to the fact that Logger has the following methods in log4j 1.2:

• isEnabledFor(Priority)
• log(Priority,Object)
• log(Priority,Object,Throwable)

whereas in log4j 1.3 there are only equivalents of this that take "Level" instead of Priority.  The only alternative here appears to be to introduce some reflection-based utility, but that would defeat the speed and efficiency of these calls whose performance is absolutely critical!

For this issue I would really like to see log4j 1.2.13 introduce:

• isEnabledFor(Level)
• log(Level,Object)
• log(Level,Object,Throwable)

Also give that most legacy libraries won't be recompiled against a hypothetical 1.2.13 real soon, there is still something to be said for either:

• Reintroducing Category and Priority
• Sure their existence is ugly but how much did they *really* hurt anyone?
• Repackaing log4j 1.3 under org.apache.log4j2.*

--
Jess Holle

[Curt Arnold-3]

On Nov 28, 2005, at 10:15 AM, Scott Deboy wrote:

> Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome  
> dependencies).
>
> I asked her if she'd be willing to contribute the appender to the  
> log4j project, and she was happy to.
>
I don't think that is an adequate audit trail for a contribution.

> She's modified the source to be java 1.3 compatible and has  
> included a couple of tests as well.
>
> If there are any issues or concerns, let's discuss them.  
> Otherwise, I'd like to commit the appender to an RSS directory, and  
> probably include it in the log4j-xml.jar target.

Since RSS 2.0 is just a specialized XML format, I'd think you'd have  
an RSSLayout, not an RSSAppender.


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

[sdeboy]

I thought about that because it would make sense to try and leverage DRFA, for example, but her appender supports using patternLayout to layout the text, and I didn't want to think about whether or not nested layouts would work.  

Also, contributions are always good, and I didn't want to suggest major changes prior to getting it into our source tree.

Scott


-----Original Message-----
From: Curt Arnold [mailto:carnold@...]
Sent: Mon 11/28/2005 11:06 AM
To: Log4J Developers List
Subject: Re: RSSAppender contribution
 

On Nov 28, 2005, at 10:15 AM, Scott Deboy wrote:

> Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome  
> dependencies).
>
> I asked her if she'd be willing to contribute the appender to the  
> log4j project, and she was happy to.
>
I don't think that is an adequate audit trail for a contribution.

> She's modified the source to be java 1.3 compatible and has  
> included a couple of tests as well.
>
> If there are any issues or concerns, let's discuss them.  
> Otherwise, I'd like to commit the appender to an RSS directory, and  
> probably include it in the log4j-xml.jar target.

Since RSS 2.0 is just a specialized XML format, I'd think you'd have  
an RSSLayout, not an RSSAppender.


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




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

[sdeboy]

I'll have her submit an email to log4j-dev.


-----Original Message-----
From: Curt Arnold [mailto:carnold@...]
Sent: Mon 11/28/2005 11:06 AM
To: Log4J Developers List
Subject: Re: RSSAppender contribution
 

On Nov 28, 2005, at 10:15 AM, Scott Deboy wrote:

> Lara D'Abreo is the author of stat4j, an RSSAppender (jdom and rome  
> dependencies).
>
> I asked her if she'd be willing to contribute the appender to the  
> log4j project, and she was happy to.
>
I don't think that is an adequate audit trail for a contribution.

> She's modified the source to be java 1.3 compatible and has  
> included a couple of tests as well.
>
> If there are any issues or concerns, let's discuss them.  
> Otherwise, I'd like to commit the appender to an RSS directory, and  
> probably include it in the log4j-xml.jar target.

Since RSS 2.0 is just a specialized XML format, I'd think you'd have  
an RSSLayout, not an RSSAppender.


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




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

[Jess Holle]

Jess Holle wrote:

Also give that most legacy libraries won't be recompiled against a hypothetical 1.2.13 real soon, there is still something to be said for either:

• Reintroducing Category and Priority
• Sure their existence is ugly but how much did they *really* hurt anyone?

It would seem that by making the constructors for Category and Priority package scoped one could prevent all but the most stupid usages from ever constructing non-Logger / non-Level instances of these classes.

That would APIs that used these classes is 1.2 to continue doing so while allowing 1.3 APIs to assume Logger and Level.  New sibling APIs could be introduced that use Logger and Level for existing APIs so that casting can be avoided except for legacy callers.

For that matter almost all implementation could be at the Category and Priority level as Logger and Level are just preferred names...

What is breaking so much source code and many existing binaries really buying?

--
Jess Holle

[Curt Arnold-3]

On Nov 28, 2005, at 1:15 PM, Scott Deboy wrote:

> I'll have her submit an email to log4j-dev.

I think a bug report is the preferred mechanism.  The Apache JIRA has  
a check box saying that you contribute the code to the ASF.  Don't  
see a similar thing in the Bugzilla attachment dialog, but you could  
make a comment that you intend the code to be contributed to ASF.


On Nov 28, 2005, at 1:15 PM, Scott Deboy wrote:
> I thought about that because it would make sense to try and  
> leverage DRFA, for example, but her appender supports using  
> patternLayout to layout the text, and I didn't want to think about  
> whether or not nested layouts would work.
>

> Also, contributions are always good, and I didn't want to suggest  
> major changes prior to getting it into our source tree.

I'd lean toward putting it into the sandbox at least at first.

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

[Elias Ross-5]

On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
>
> What is breaking so much source code and many existing binaries really
> buying?

In my opinion, removing "Category" would be just like Sun deciding to
remove "java.util.Emumeration" or some other classes now marked as
"deprecated."

I know given the amount of breakage so far in Log4J 1.3 (and the
existing potential deadlock conditions in 1.2) JBoss probably would
consider shipping with the JDK logging system instead.

Although JBoss wouldn't break under 1.3, user apps would.  JBoss might
adopt the JDK logger for its internal use, and for user apps, the user
would have a choice.



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

[Paul Smith-2]

On 29/11/2005, at 7:47 AM, Elias Ross wrote:

> On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
>>
>> What is breaking so much source code and many existing binaries  
>> really
>> buying?
>
> In my opinion, removing "Category" would be just like Sun deciding to
> remove "java.util.Emumeration" or some other classes now marked as
> "deprecated."

True.  I'm personally a bit unclear as to whether we are trying to  
maintain binary compatibility with log4j 1.2.x.  I hope so.  I think  
we as a dev team should highlight that this is a primary goal of the  
1.3 release or explicitly mention that we're not.  If we are going to  
aim for compatibility then Jess' reports are disturbing (putting the  
tone of the email aside, the content is sounding valid at first glance).

Please bear in mind that we're in Alpha stage at the moment, there's  
still a lot of change probably left to go.  I would consider what we  
have published so far for 1.3 as a "work in progress, comments  
please" type release.

Paul

[Jess Holle]

I believe that's indicative of the sort of decision making log4j 1.3's current state forces.

I'm sure (or at least highly hopeful) that a lot of good work has gone into 1.3 but:

1. We need a deadlock fix sooner rather than later in 1.2 if not 1.3.
2. 1.3 *must* maintain better compatibility with 1.2 than the current documentation indicates is planned *or* be repackaged under another package name as I see it.  Right now 1.2 and 1.3 classes are under the same names but any given piece of software must be compiled against just one of these and will utterly fail under the other at this time.  That is utterly unworkable.

If the log4j team won't address (1) without burdening us with (2), then perhaps those of us needing a fix to (1) should fix issue (2) in a fork of log4j 1.3!  The problems are not rocket science.  [The incompatibilities intrinsic in fixing the deadlock will just have to be accepted, of course.]

--
Jess Holle

Elias Ross wrote:

On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
  

What is breaking so much source code and many existing binaries really
buying?
    

In my opinion, removing "Category" would be just like Sun deciding to
remove "java.util.Emumeration" or some other classes now marked as
"deprecated."

I know given the amount of breakage so far in Log4J 1.3 (and the
existing potential deadlock conditions in 1.2) JBoss probably would
consider shipping with the JDK logging system instead.

Although JBoss wouldn't break under 1.3, user apps would.  JBoss might
adopt the JDK logger for its internal use, and for user apps, the user
would have a choice.

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

[Jess Holle]

Paul Smith wrote:

> On 29/11/2005, at 7:47 AM, Elias Ross wrote:
>
>> On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
>>
>>> What is breaking so much source code and many existing binaries  really
>>> buying?
>>
>> In my opinion, removing "Category" would be just like Sun deciding to
>> remove "java.util.Emumeration" or some other classes now marked as
>> "deprecated."
>
> True.  I'm personally a bit unclear as to whether we are trying to  
> maintain binary compatibility with log4j 1.2.x.  I hope so.

It would really seem that there has been no attempt along these lines to
date.  logj4 1.3 is currently only an alpha so issues are to be expected
at this point, *but* I believe binary compatibility and removal of
Category and Priority are mutually exclusive.  [I'd be happy to be
proven wrong on this.]  The best one could seemingly achieve is
introduction of a log4j 1.2.xx release which binaries compiled agianst
will also work with log4j 1.3.  If binaries built against any currently
existing 1.2.x release are to be supported then we have to keep Category
and Priority around as I see it.

> I think  we as a dev team should highlight that this is a primary goal
> of the  1.3 release or explicitly mention that we're not.

If this is not to be a goal, then *please* place all the classes under
other package names and clearly document this situation.

I do not believe such a fragmentation of the log4j ecosystem is
justified or productive, however.

> If we are going to aim for compatibility then Jess' reports are
> disturbing (putting the  tone of the email aside, the content is
> sounding valid at first glance).

I apologize for the tone.

I have spent a great deal of time converting a great deal of legacy
logging code and infrastructure to (directly, no JCL) use log4j and
creating my own JMX MBeans to manage all manage and monitor log4j (due
to a number of deeply rooted issues I encountered in log4j's own MBeans).

After all of this, I am now confronted with deadlocks vs. the 1.3 issues
-- a rock-and-a-hard-place which is more than a bit distressing!

> Please bear in mind that we're in Alpha stage at the moment, there's  
> still a lot of change probably left to go.  I would consider what we  
> have published so far for 1.3 as a "work in progress, comments  
> please" type release.

I hope so.  I'm not saying that 1.3 is not a good step forward in many
respects.  I do believe that some care and attention is necessary to
mend compatibility with 1.2 and that the Category and Priority removal
attempts has much more serious side-effects than requiring source code
updates...

--
Jess Holle

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

[Paul Smith-2]

>

> It would really seem that there has been no attempt along these  
> lines to date.  logj4 1.3 is currently only an alpha so issues are  
> to be expected at this point, *but* I believe binary compatibility  
> and removal of Category and Priority are mutually exclusive.  [I'd  
> be happy to be proven wrong on this.]  The best one could seemingly  
> achieve is introduction of a log4j 1.2.xx release which binaries  
> compiled agianst will also work with log4j 1.3.  If binaries built  
> against any currently existing 1.2.x release are to be supported  
> then we have to keep Category and Priority around as I see it.
>

I'm no binary-compatibility expert, but I can't see how we can  

maintain it while dropping Category.  I'm beginning to think that we  
(log4j community) are very much as Elias pointed out.  Stuck with  
marking it as deprecated, but 'forever' keeping it.  Putting aside  
technical aspects of keeping things clean, all we would do is  
alienate the community.  There's no point having a rockin' API if  
everyone has been burnt by it and moved on to other things.
>> I think  we as a dev team should highlight that this is a primary  
>> goal of the  1.3 release or explicitly mention that we're not.
>
> If this is not to be a goal, then *please* place all the classes  
> under other package names and clearly document this situation.
>
> I do not believe such a fragmentation of the log4j ecosystem is  
> justified or productive, however.

That is the last thing I'd like to see..

>
>> If we are going to aim for compatibility then Jess' reports are  
>> disturbing (putting the  tone of the email aside, the content is  
>> sounding valid at first glance).
>
> I apologize for the tone.
>
> I have spent a great deal of time converting a great deal of legacy  
> logging code and infrastructure to (directly, no JCL) use log4j and  
> creating my own JMX MBeans to manage all manage and monitor log4j  
> (due to a number of deeply rooted issues I encountered in log4j's  
> own MBeans).
>
> After all of this, I am now confronted with deadlocks vs. the 1.3  
> issues -- a rock-and-a-hard-place which is more than a bit  
> distressing!

I understand completely.  You've probably had lots of road-rage at  
this point.  My experience is that keeping your tone lighter will get  
your end results a lot quicker! :)
>

On a side note, you mentioned you have done a lot of work in the JMX  
area for log4j..  Would you be interested in floating what you have  
done to the community, and if we think it's good, consider donating  
it?  (it's a bit of a legal process, and likely to require your  
company to sign something).

cheers,

Paul

[Jess Holle]

Paul Smith wrote:

On a side note, you mentioned you have done a lot of work in the JMX  area for log4j..  Would you be interested in floating what you have  done to the community, and if we think it's good, consider donating  it?  (it's a bit of a legal process, and likely to require your  company to sign something).

I could look into floating this, but since it was done on work time doing so may require some hoop jumping :-)

The other issue is that at this point the implementation is heavily based on various MBean base class and utility classes into which I've extracted capabilities shared by many of our MBeans.

Some tidbits I've addressed include:

• Support for multiple LoggerRepository's
• For instance, each web app can have its LoggerRepository and MBeans specifically for it.  The servlet engine itself may separately have yet another LoggerRepository and other MBeans for this.
  
• This is probably the biggest/deepest change from the existing log4j code.  My LoggerRepository monitoring MBeans can be rooted anywhere in the ObjectName tree and all related MBeans will be given relative names.  All the code thus works against a LoggerRepository reference maintained in the MBeans and passed into the construction thereof.
  
• Integrated configuration file watching (with appropriate thread termination on web app shutdown, etc)
• This is my own implementation due to issues with the watching built into log4j 1.2.
  
• Specific MBean subclasses for various appender types so you can tail log files from JMX, properly interact with asynch appenders, etc.
  
• Numerous bugs

--
Jess Holle

[Jess Holle]

Paul Smith wrote:

>> It would really seem that there has been no attempt along these  
>> lines to date.  logj4 1.3 is currently only an alpha so issues are  
>> to be expected at this point, *but* I believe binary compatibility  
>> and removal of Category and Priority are mutually exclusive.  [I'd  
>> be happy to be proven wrong on this.]  The best one could seemingly  
>> achieve is introduction of a log4j 1.2.xx release which binaries  
>> compiled agianst will also work with log4j 1.3.  If binaries built  
>> against any currently existing 1.2.x release are to be supported  
>> then we have to keep Category and Priority around as I see it.
>
> I'm no binary-compatibility expert, but I can't see how we can  
> maintain it while dropping Category.  I'm beginning to think that we  
> (log4j community) are very much as Elias pointed out.  Stuck with  
> marking it as deprecated, but 'forever' keeping it.  Putting aside  
> technical aspects of keeping things clean, all we would do is  
> alienate the community.  There's no point having a rockin' API if  
> everyone has been burnt by it and moved on to other things.

Actually I believe I may have been a bit hasty in jumping to the
conclusion that Category cannot be removed.  I do not have any cases
wherein code written against Logger and Level -- as per what are now
fairly longstanding 1.3 compatibility guidelines -- is not binary
compatible with 1.3 when compiled against 1.2.  There may or may not be
any such cases.  The other question is how many current versions of open
source libraries, etc, still use Category directly.  As one related
example, the RootLogger class only came into existence in a rather
recent 1.2.x release so prior to that there was no choice but to use
RootCategory for such things.

I believe the examples showing the need for Priority to maintain binary
compatibility are fairly clear and unfortunately affect some fairly
frequently used methods of Logger.  In our case, these methods affect
dozens of classes spread throughout numerous modules, whereas the
various source-code changes necessary for 1.3 were limited to relative
few files in a few modules which generally were making more elaborate
usage of log4j than what might be consider the 80-90% case of simple
Logger/Level usage.

--
Jess Holle

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