You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Simon Kitching <sk...@apache.org> on 2005/06/17 14:10:33 UTC
[logging] Log4J forward compatibility with version 1.3
Hi Log4j developers,
I'm a maintainer of jakarta commons-logging. We're preparing for a new
release and I'm checking up on compatibility with what will become log4j
version 1.3. We don't intend to wait for 1.3 to be released, but would
like to ensure that JCL is compatible with log4j 1.3 when you do release
it.
As I understand it:
Log4j 1.2:
Priority has constants of type Priority
Level has constants of type Level
Level extends Priority
Category has methods that take Priority objects
Category has no methods that take Level objects
Logger extends Category and provides no significant additional methods
Log4j 1.3:
Priority now extends Level
Priority has no constants; it just inherits them from Level
Logger still extends Category
Category now has methods that take Level objects
This implies that any code that explicitly passes Level objects to
Logger methods and is compiled against log4j 1.2 will not be compatible
with log4j 1.3.
Example:
logger.log(FQCN, Level.DEBUG, message, null );
<output>
Exception in thread "main" java.lang.VerifyError: (class: Test1, method:
main signature: ([Ljava/lang/String;)V) Incompatible argument to
function
</output>
The issue is that when compiled against 1.2, the compiler determines
that the call is actually to method
Category.log(String, Priority, String, Throwable)
and so encodes that info in the .class file.
However when run against version 1.3 this code fails because Level.DEBUG
cannot be converted to a Priority object; Level is no longer a subclass
of Priority.
This code is unfortunately exactly what commons-logging uses. But it's
probably fairly common usage.
Is log4j 1.3 really going to be structured like this? It seems to me
this will make it impossible for JCL to be released now in a manner
compatible with log4j1.3 (it is not acceptable in my opinion to release
code compiled against log4j 1.3 alpha..).
Note that in May of 2004, a patch was committed to JCL with this commit
message:
<quote>
Modifications required to ensure Log4JLogger works with both 1.2.x and
1.3 Log4J. Submitted by Ceki Gulcu.
</quote>
which wraps all our existing calls:
if(is12) {
getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
} else {
getLogger().log(FQCN, Level.DEBUG, message, t );
}
I can't understand the point of this patch though. And it definitely
does not resolve the issue.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2005-06-17 at 15:54 +0200, Ceki Gülcü wrote:
> [1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=108504642518488&w=2
Unforunately, the referenced email just contains two further links to
the actual technical explanation. And neither of those links work.
Does anyone have working links to the reasoning behind the current
approach to deprecating/removing Category and Priority?
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Thu, 23 Jun 2005, Paul Smith wrote:
| I'm a bit perplexed why we swapped Level and priority and not
| category/logger... something doesn't feel right, but I do remember the switch
| happening a while back, but it's a bit of a fog I must admit.
|
| We can't have one and not the other, so we'll need to make a decision.
Suggestion: get rid of Category! DELETE it! People won't notice it in the
sheer happiness they're still fogged in for finally having the TRACE
level.
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Paul Smith <ps...@aconex.com>.
I'm a bit perplexed why we swapped Level and priority and not
category/logger... something doesn't feel right, but I do remember
the switch happening a while back, but it's a bit of a fog I must admit.
We can't have one and not the other, so we'll need to make a decision.
Paul
On 23/06/2005, at 8:08 PM, Simon Kitching wrote:
> On Mon, 2005-06-20 at 18:12 +1200, Simon Kitching wrote:
>
>> On Sat, 2005-06-18 at 16:23 +0200, Ceki Gülcü wrote:
>>
>>> I see your point. Assuming everyone involved in log4j is
>>> cognizant of
>>> this problem, I think you can expect current arrangement of Logger,
>>> Category, Level etc. to persist through until 1.3 final.
>>>
>>
>> In the 1.3alpha6 release has swapped the hierarchy positions for
>> Level
>> and Priority.
>>
>> But it hasn't swapped Category and Logger. Is this still in the
>> plan for
>> 1.3? If so, when is this work likely to be done?
>>
>
> Anyone got an opinion on this?
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2005-06-20 at 18:12 +1200, Simon Kitching wrote:
> On Sat, 2005-06-18 at 16:23 +0200, Ceki Gülcü wrote:
> > I see your point. Assuming everyone involved in log4j is cognizant of
> > this problem, I think you can expect current arrangement of Logger,
> > Category, Level etc. to persist through until 1.3 final.
>
> In the 1.3alpha6 release has swapped the hierarchy positions for Level
> and Priority.
>
> But it hasn't swapped Category and Logger. Is this still in the plan for
> 1.3? If so, when is this work likely to be done?
Anyone got an opinion on this?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Curt Arnold <ca...@houston.rr.com>.
On Jul 1, 2005, at 6:18 PM, Simon Kitching wrote:
> On Fri, 2005-07-01 at 16:13 -0700, Mark Womack wrote:
>
>> This all seems sane to me. JCL will provide a way (eventually) to
>> choose
>> between the Log4j12Logger and the future Log4j13Logger? There is
>> a request
>> to add a method of determining the log4j version which we will be
>> implementing for the 1.3 version. I'm sure that will help.
>>
>
> The JCl code tests for version by checking:
> Priority.class.isAssignableFrom(Level.class)
>
> As long as this isn't true in 1.3 everything is fine. Note that it's
> also fine for the Priority class to be missing; NoClassDefFound for
> this
> expression also is taken as not-1.2 :-)
I'd much rather prefer to provide some other pr additional mechanism
since my gut feeling is that will will have to restore the 1.2
relationship between these classes (Level extends Priority) in order
to prevent wide-spread VerifyError when using log4j 1.3 with code
compiled against log4j 1.2.
There are a couple of scenarios:
1) log4j 1.3 is sufficiently binary compatible with log4j 1.2 that
there is no need or desire for a log4j 1.3 specific wrapper
2) log4j 1.3 is sufficiently binary compatible that there is no need,
but there is a desire for a log4j 1.3 specific wrapper to support
some feature or optimization.
3) log4j 1.3 isn't sufficiently binary compatible and needs a log4j
1.3 specific wrapper and Priority extends Level (current CVS HEAD).
4) log4j 1.3 isn't sufficiently binary compatible and needs a log4j
1.3 specific wrapper and Level extends Priority.
As long as we stay away from scenario 4, the current approach in
Log4J12Logger would be work okay. It would work with log4j 1.2 and a
hypothetical binary compatible log4j 1.3 and quickly fail with the
previous log4j 1.3 alphas. However, I'd hate to paint myself a
corner until scenario 4 with the initial log4j 1.3 release can be
totally ruled out.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [logging] Log4J forward compatibility with version 1.3
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2005-07-01 at 16:13 -0700, Mark Womack wrote:
> This all seems sane to me. JCL will provide a way (eventually) to choose
> between the Log4j12Logger and the future Log4j13Logger? There is a request
> to add a method of determining the log4j version which we will be
> implementing for the 1.3 version. I'm sure that will help.
The JCl code tests for version by checking:
Priority.class.isAssignableFrom(Level.class)
As long as this isn't true in 1.3 everything is fine. Note that it's
also fine for the Priority class to be missing; NoClassDefFound for this
expression also is taken as not-1.2 :-)
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [logging] Log4J forward compatibility with version 1.3
Posted by Mark Womack <wo...@adobe.com>.
This all seems sane to me. JCL will provide a way (eventually) to choose
between the Log4j12Logger and the future Log4j13Logger? There is a request
to add a method of determining the log4j version which we will be
implementing for the 1.3 version. I'm sure that will help.
-Mark
> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: Friday, July 01, 2005 4:05 PM
> To: 'Log4J Developers List'
> Subject: RE: [logging] Log4J forward compatibility with version 1.3
>
> JCL 1.1 is likely to be released within the next 6 weeks or so (warning:
> crystal-ball-gazing prediction). So log4j 1.3 won't be out.
>
> And the general consensus is that we will *not* release code based on
> compiling against 1.3 alpha. Instead JCL will provide a Log4j12Logger
> class that specifically supports log4j 1.2 stuff. When log4j 1.3 is
> released the plan is to release an update to JCL with a Log4j13Logger
> class.
>
> So whether you do all the hierarchy-swapping or simply delete
> Category/Priority doesn't make any difference to JCL. The only benefit
> to the old plan is that it was possible to provide one class that worked
> with both libs but we're not doing that as:
> * it means releasing now with code compiled against the alpha, or
> * waiting for log4j 1.3 which still appears to be quite a way off.
>
> Regards,
>
> Simon
>
> On Fri, 2005-07-01 at 09:46 -0700, Mark Womack wrote:
> > [getting ready to duck rotten eggs and tomatoes...]
> >
> > What about just doing what the deprecation warning has been saying for
> all
> > of the 1.2 release and getting rid of Category and Priority altogether
> in
> > the 1.3 release? I think everyone has been fairly warned about it.
> >
> > Simon, is there a pending release of JCL that is waiting for an answer
> to
> > this issue? It is on my list of items to look at in more detail this
> > weekend. Don't know if I will have an answer to suggest, but I hope to
> be
> > more familiar with it.
> >
> > -Mark
> >
> > > -----Original Message-----
> > > From: Simon Kitching [mailto:skitching@apache.org]
> > > Sent: Sunday, June 19, 2005 11:12 PM
> > > To: Log4J Developers List
> > > Subject: Re: [logging] Log4J forward compatibility with version 1.3
> > >
> > > On Sat, 2005-06-18 at 16:23 +0200, Ceki Gülcü wrote:
> > > > I see your point. Assuming everyone involved in log4j is cognizant
> of
> > > > this problem, I think you can expect current arrangement of Logger,
> > > > Category, Level etc. to persist through until 1.3 final.
> > >
> > > In the 1.3alpha6 release has swapped the hierarchy positions for Level
> > > and Priority.
> > >
> > > But it hasn't swapped Category and Logger. Is this still in the plan
> for
> > > 1.3? If so, when is this work likely to be done?
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [logging] Log4J forward compatibility with version 1.3
Posted by Simon Kitching <sk...@apache.org>.
JCL 1.1 is likely to be released within the next 6 weeks or so (warning:
crystal-ball-gazing prediction). So log4j 1.3 won't be out.
And the general consensus is that we will *not* release code based on
compiling against 1.3 alpha. Instead JCL will provide a Log4j12Logger
class that specifically supports log4j 1.2 stuff. When log4j 1.3 is
released the plan is to release an update to JCL with a Log4j13Logger
class.
So whether you do all the hierarchy-swapping or simply delete
Category/Priority doesn't make any difference to JCL. The only benefit
to the old plan is that it was possible to provide one class that worked
with both libs but we're not doing that as:
* it means releasing now with code compiled against the alpha, or
* waiting for log4j 1.3 which still appears to be quite a way off.
Regards,
Simon
On Fri, 2005-07-01 at 09:46 -0700, Mark Womack wrote:
> [getting ready to duck rotten eggs and tomatoes...]
>
> What about just doing what the deprecation warning has been saying for all
> of the 1.2 release and getting rid of Category and Priority altogether in
> the 1.3 release? I think everyone has been fairly warned about it.
>
> Simon, is there a pending release of JCL that is waiting for an answer to
> this issue? It is on my list of items to look at in more detail this
> weekend. Don't know if I will have an answer to suggest, but I hope to be
> more familiar with it.
>
> -Mark
>
> > -----Original Message-----
> > From: Simon Kitching [mailto:skitching@apache.org]
> > Sent: Sunday, June 19, 2005 11:12 PM
> > To: Log4J Developers List
> > Subject: Re: [logging] Log4J forward compatibility with version 1.3
> >
> > On Sat, 2005-06-18 at 16:23 +0200, Ceki Gülcü wrote:
> > > I see your point. Assuming everyone involved in log4j is cognizant of
> > > this problem, I think you can expect current arrangement of Logger,
> > > Category, Level etc. to persist through until 1.3 final.
> >
> > In the 1.3alpha6 release has swapped the hierarchy positions for Level
> > and Priority.
> >
> > But it hasn't swapped Category and Logger. Is this still in the plan for
> > 1.3? If so, when is this work likely to be done?
> >
> > Regards,
> >
> > Simon
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Curt Arnold <ca...@houston.rr.com>.
On Jul 1, 2005, at 11:46 AM, Mark Womack wrote:
> [getting ready to duck rotten eggs and tomatoes...]
>
> What about just doing what the deprecation warning has been saying
> for all
> of the 1.2 release and getting rid of Category and Priority
> altogether in
> the 1.3 release? I think everyone has been fairly warned about it.
>
> Simon, is there a pending release of JCL that is waiting for an
> answer to
> this issue? It is on my list of items to look at in more detail this
> weekend. Don't know if I will have an answer to suggest, but I
> hope to be
> more familiar with it.
>
> -Mark
If there was a way of doing that that did not break binary
compatibility with applications that used 1.2 but did not reference
Category or Priority, I'd might consider it, but I'm not sure that it
could be done. The only safe path I see to possibly reaching that is
to continue trying to get to binary compatibility with the log4j
1.2.x unit tests and when that is successful, see if they can be
eliminated entirely without breaking binary compatibility.
The path I see (or hope is there) out of this swamp is:
1. Get the log4j 1.2 unit tests successfully compiling against CVS
HEAD. With the exceptions of DRFATestCase (which doesn't test the
external API) and the MyPatternLayout/MyPatternParser classes
supporting PatternLayoutTest.test14 which tests custom pattern
parsers which may be an extremely rare use case, I've got this
working locally and should commit soon.
2. Get the log4j 1.2 unit tests passing against the CVS HEAD when
compiled against the CVS HEAD. The most significant roadblock to
this is internal logging messages polluting the output. My intended
approach to this is to restore the log4j 1.2 behavior (info and
higher to the console unless debug="true" on configuration) unless
specifically overridden in the configuration file.
3. Get the log4j 1.2 unit tests passed against the CVS HEAD when
compiled against log4j 1.2. I assume this will require reverting the
inheritance relationship between Category and Logger and Priority and
Level. When we've got this working, then we can do what-if's to see
if we can totally eliminate the Category and Priority without raising
the dreaded VerifyError exception on class load.
As far as I can tell (but I haven't did any significant research), it
is unlikely that an arbitrary app compiled against log4j 1.2 would
just work if you dropped the current CVS HEAD in the classpath.
However, mileage may vary depending on the JVM. I think we would
like to get to the point that almost all applications would. At
least that is what we have been historically saying about the CVS HEAD.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [logging] Log4J forward compatibility with version 1.3
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> What about just doing what the deprecation warning has been saying for all
> of the 1.2 release and getting rid of Category and Priority altogether in
> the 1.3 release? I think everyone has been fairly warned about it.
I've been itching to do just that. +1.
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management / School of Engineering
Cambridge, MA USA
yoavsh@sloan.mit.edu / yoavs@computer.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [logging] Log4J forward compatibility with version 1.3
Posted by Mark Womack <wo...@adobe.com>.
[getting ready to duck rotten eggs and tomatoes...]
What about just doing what the deprecation warning has been saying for all
of the 1.2 release and getting rid of Category and Priority altogether in
the 1.3 release? I think everyone has been fairly warned about it.
Simon, is there a pending release of JCL that is waiting for an answer to
this issue? It is on my list of items to look at in more detail this
weekend. Don't know if I will have an answer to suggest, but I hope to be
more familiar with it.
-Mark
> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: Sunday, June 19, 2005 11:12 PM
> To: Log4J Developers List
> Subject: Re: [logging] Log4J forward compatibility with version 1.3
>
> On Sat, 2005-06-18 at 16:23 +0200, Ceki Gülcü wrote:
> > I see your point. Assuming everyone involved in log4j is cognizant of
> > this problem, I think you can expect current arrangement of Logger,
> > Category, Level etc. to persist through until 1.3 final.
>
> In the 1.3alpha6 release has swapped the hierarchy positions for Level
> and Priority.
>
> But it hasn't swapped Category and Logger. Is this still in the plan for
> 1.3? If so, when is this work likely to be done?
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2005-06-18 at 16:23 +0200, Ceki Gülcü wrote:
> I see your point. Assuming everyone involved in log4j is cognizant of
> this problem, I think you can expect current arrangement of Logger,
> Category, Level etc. to persist through until 1.3 final.
In the 1.3alpha6 release has swapped the hierarchy positions for Level
and Priority.
But it hasn't swapped Category and Logger. Is this still in the plan for
1.3? If so, when is this work likely to be done?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Ceki Gülcü <li...@qos.ch>.
At 02:50 AM 6/18/2005, Simon Kitching wrote:
> >
> > No doubt that you are right but I wonder how you reached this conclusion?
> > The java.lang.VerifyError
> > is so cryptic. Which version of the JDK are you using?
>
>The output is the same on JDK 1.3 and JDK 1.5. I wrote a trivial test
>program that just called logger.log(FQCN, Level.DEBUG, message, null)
>then ran "javap -c ..."; the bytecode output clearly shows which method
>has been bound to.
Thanks Simon. That's a useful technique to put in the bag of tricks to
know.
>Well, this patch *does* allow code compiled against 1.3 to run against
>1.2. But it does it via a rather dodgy assumption: that the compiler
>won't try to check
> getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
>at compile-time. Casting a constant to a specific type is certainly
>something that *could* be done at compile time, and would report an
>error. I wouldn't be at all surprised to see future versions of javac do
>this check. And I bet this code wouldn't compile with gcj. NB: Of course
>the check has to be done at runtime too, for typesafety but that doesn't
>mean the compiler won't do it at compiletime too.
Excellent point. I was not aware of it.
>And it's moot anyway as JCL can't make an official release based upon
>compiling against log4j-1.3 alpha code.
Well, we can expect the code to run fine in both versions of log4j, so
your position may be a little too categoric. I am not sure there is a
better alternative, but again, it's your decision ultimately.
>If log4j1.3 really is going to be binary-incompatible against log4j1.2
>(ie we can't release one Log4JLogger class compiled against 1.2 that
>will work against 1.3) then I would probably recommend that we split
>Log4JLogger into two parts: Log4J12Logger and Log4J13Logger. The former
>would be compiled against log4j-1.2 and the latter against log4j-1.3
>alpha code. That's a weird distortion of our build process though;
>normally a build for any project is done against one consistent
>classpath.
>
>And releasing code compiled against an alpha release isn't very nice. It
>would be very embarrassing if log4j then changed API before an official
>1.3 release which broke the logger in JCL.
I see your point. Assuming everyone involved in log4j is cognizant of
this problem, I think you can expect current arrangement of Logger,
Category, Level etc. to persist through until 1.3 final.
You may want to ask for a pledge from the group which I would expect
to be granted as well as honored in the future.
>The alternative would be to not bundle support for 1.3 in the next
>release, and release log4j 1.3 support as a JCL "add-on" available as a
>separate download once log4j 1.3 is released.
Is that better than the current status where we are at least assured
to have runtime compatibility?
>Are you really sure you want to break binary compatibility between 1.2
>and 1.3??
Breaking compile-time compatibility at this core level was not
intentional, that much should be obvious, at least I would hope so.
Moreover, I still consider runtime compatibility to be valuable,
something not to be hastily discarded.
>Regards,
>
>Simon
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Simon Kitching <sk...@apache.org>.
Hi,
On Fri, 2005-06-17 at 15:54 +0200, Ceki Gülcü wrote:
> >Log4j 1.3:
> > Priority now extends Level
> > Priority has no constants; it just inherits them from Level
> > Logger still extends Category
> > Category now has methods that take Level objects
> >
> >This implies that any code that explicitly passes Level objects to
> >Logger methods and is compiled against log4j 1.2 will not be compatible
> >with log4j 1.3.
>
> Unfortunately, you are correct. Please refer to [1] for background
> information.
>
> >Example:
> > logger.log(FQCN, Level.DEBUG, message, null );
> >
> ><output>
> >Exception in thread "main" java.lang.VerifyError: (class: Test1, method:
> >main signature: ([Ljava/lang/String;)V) Incompatible argument to
> >function
> ></output>
> >
> >The issue is that when compiled against 1.2, the compiler determines
> >that the call is actually to method
> > Category.log(String, Priority, String, Throwable)
> >and so encodes that info in the .class file.
>
> No doubt that you are right but I wonder how you reached this conclusion?
> The java.lang.VerifyError
> is so cryptic. Which version of the JDK are you using?
The output is the same on JDK 1.3 and JDK 1.5. I wrote a trivial test
program that just called logger.log(FQCN, Level.DEBUG, message, null)
then ran "javap -c ..."; the bytecode output clearly shows which method
has been bound to.
>
> >However when run against version 1.3 this code fails because Level.DEBUG
> >cannot be converted to a Priority object; Level is no longer a subclass
> >of Priority.
> >
> >This code is unfortunately exactly what commons-logging uses. But it's
> >probably fairly common usage.
> >
> >Is log4j 1.3 really going to be structured like this? It seems to me
> >this will make it impossible for JCL to be released now in a manner
> >compatible with log4j1.3 (it is not acceptable in my opinion to release
> >code compiled against log4j 1.3 alpha..).
> >
> >Note that in May of 2004, a patch was committed to JCL with this commit
> >message:
> ><quote>
> >Modifications required to ensure Log4JLogger works with both 1.2.x and
> >1.3 Log4J. Submitted by Ceki Gulcu.
> ></quote>
> >which wraps all our existing calls:
> > if(is12) {
> > getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
> > } else {
> > getLogger().log(FQCN, Level.DEBUG, message, t );
> > }
> >I can't understand the point of this patch though. And it definitely
> >does not resolve the issue.
>
> The rationale of the patch is explained in [2], that is bug #28933. In
> short, the patch ensures that JCL compiled against log4j 1.3.x will run
> fine with log4j 1.2.x. I was not able to find a simple solution to make JCL
> compiled against log4j 1.2.x run with log4j 1.3.
Well, this patch *does* allow code compiled against 1.3 to run against
1.2. But it does it via a rather dodgy assumption: that the compiler
won't try to check
getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
at compile-time. Casting a constant to a specific type is certainly
something that *could* be done at compile time, and would report an
error. I wouldn't be at all surprised to see future versions of javac do
this check. And I bet this code wouldn't compile with gcj. NB: Of course
the check has to be done at runtime too, for typesafety but that doesn't
mean the compiler won't do it at compiletime too.
And it's moot anyway as JCL can't make an official release based upon
compiling against log4j-1.3 alpha code.
If log4j1.3 really is going to be binary-incompatible against log4j1.2
(ie we can't release one Log4JLogger class compiled against 1.2 that
will work against 1.3) then I would probably recommend that we split
Log4JLogger into two parts: Log4J12Logger and Log4J13Logger. The former
would be compiled against log4j-1.2 and the latter against log4j-1.3
alpha code. That's a weird distortion of our build process though;
normally a build for any project is done against one consistent
classpath.
And releasing code compiled against an alpha release isn't very nice. It
would be very embarrassing if log4j then changed API before an official
1.3 release which broke the logger in JCL.
The alternative would be to not bundle support for 1.3 in the next
release, and release log4j 1.3 support as a JCL "add-on" available as a
separate download once log4j 1.3 is released.
Are you really sure you want to break binary compatibility between 1.2
and 1.3??
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Log4J forward compatibility with version 1.3
Posted by Ceki Gülcü <li...@qos.ch>.
Comments inline.
At 02:10 PM 6/17/2005, Simon Kitching wrote:
>Hi Log4j developers,
>
>I'm a maintainer of jakarta commons-logging. We're preparing for a new
>release and I'm checking up on compatibility with what will become log4j
>version 1.3. We don't intend to wait for 1.3 to be released, but would
>like to ensure that JCL is compatible with log4j 1.3 when you do release
>it.
>
>As I understand it:
>
>Log4j 1.2:
> Priority has constants of type Priority
> Level has constants of type Level
> Level extends Priority
> Category has methods that take Priority objects
> Category has no methods that take Level objects
> Logger extends Category and provides no significant additional methods
Correct. Incidentally, those constants in Priority are really of type
Level. This ensures, that log4j 1.2 will not (and cannot) produce Priority
objects other than Level objects. (In log4j 1.2, all Priority objects are
always of type Level.)
>Log4j 1.3:
> Priority now extends Level
> Priority has no constants; it just inherits them from Level
> Logger still extends Category
> Category now has methods that take Level objects
>
>This implies that any code that explicitly passes Level objects to
>Logger methods and is compiled against log4j 1.2 will not be compatible
>with log4j 1.3.
Unfortunately, you are correct. Please refer to [1] for background
information.
>Example:
> logger.log(FQCN, Level.DEBUG, message, null );
>
><output>
>Exception in thread "main" java.lang.VerifyError: (class: Test1, method:
>main signature: ([Ljava/lang/String;)V) Incompatible argument to
>function
></output>
>
>The issue is that when compiled against 1.2, the compiler determines
>that the call is actually to method
> Category.log(String, Priority, String, Throwable)
>and so encodes that info in the .class file.
No doubt that you are right but I wonder how you reached this conclusion?
The java.lang.VerifyError
is so cryptic. Which version of the JDK are you using?
>However when run against version 1.3 this code fails because Level.DEBUG
>cannot be converted to a Priority object; Level is no longer a subclass
>of Priority.
>
>This code is unfortunately exactly what commons-logging uses. But it's
>probably fairly common usage.
>
>Is log4j 1.3 really going to be structured like this? It seems to me
>this will make it impossible for JCL to be released now in a manner
>compatible with log4j1.3 (it is not acceptable in my opinion to release
>code compiled against log4j 1.3 alpha..).
>
>Note that in May of 2004, a patch was committed to JCL with this commit
>message:
><quote>
>Modifications required to ensure Log4JLogger works with both 1.2.x and
>1.3 Log4J. Submitted by Ceki Gulcu.
></quote>
>which wraps all our existing calls:
> if(is12) {
> getLogger().log(FQCN, (Priority) Level.DEBUG, message, t );
> } else {
> getLogger().log(FQCN, Level.DEBUG, message, t );
> }
>I can't understand the point of this patch though. And it definitely
>does not resolve the issue.
The rationale of the patch is explained in [2], that is bug #28933. In
short, the patch ensures that JCL compiled against log4j 1.3.x will run
fine with log4j 1.2.x. I was not able to find a simple solution to make JCL
compiled against log4j 1.2.x run with log4j 1.3.
>Regards,
>
>Simon
I hope this could shed some light onto the matter.
[1] http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=108504642518488&w=2
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=28933
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org