You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2006/01/19 06:30:57 UTC
[logging] log4j transition
Hi,
Given that log4j 1.3 still hasn't released, I would like to revert the
name of the log4J12Logger back to Log4JLogger for the 1.1 release, and
remove the Log4J13Logger.
The name-change will break any config files that explicitly specify that
logger name. That breakage will have to occur eventually as long as the
log4j team keep to their plan of making a binary-incompatible release.
However I think we've got enough in this release without buying into
that issue too. In addition, I hate guessing the future on this; if we
release a Log4J13Logger class and then it doesn't work with the real
log4j13 that would be embarrassing.
Any objections to reverting to the old naming and removing Log4J13Logger
for now? [NB: I wrote it :-].
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j transition
Posted by Dennis Lundberg <de...@mdh.se>.
Simon Kitching wrote:
> Hi,
>
> Given that log4j 1.3 still hasn't released, I would like to revert the
> name of the log4J12Logger back to Log4JLogger for the 1.1 release, and
> remove the Log4J13Logger.
+1
> The name-change will break any config files that explicitly specify that
> logger name. That breakage will have to occur eventually as long as the
> log4j team keep to their plan of making a binary-incompatible release.
> However I think we've got enough in this release without buying into
> that issue too. In addition, I hate guessing the future on this; if we
> release a Log4J13Logger class and then it doesn't work with the real
> log4j13 that would be embarrassing.
>
> Any objections to reverting to the old naming and removing Log4J13Logger
> for now? [NB: I wrote it :-].
Anything that makes upgrading as easy as possible for JCL users is a
good thing.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j transition
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2006-01-19 at 18:30 +1300, Simon Kitching wrote:
> Hi,
>
> Given that log4j 1.3 still hasn't released, I would like to revert the
> name of the log4J12Logger back to Log4JLogger for the 1.1 release, and
> remove the Log4J13Logger.
+1
> The name-change will break any config files that explicitly specify that
> logger name. That breakage will have to occur eventually as long as the
> log4j team keep to their plan of making a binary-incompatible release.
> However I think we've got enough in this release without buying into
> that issue too. In addition, I hate guessing the future on this; if we
> release a Log4J13Logger class and then it doesn't work with the real
> log4j13 that would be embarrassing.
>
> Any objections to reverting to the old naming and removing Log4J13Logger
> for now? [NB: I wrote it :-].
go ahead
consider taking a tag before hand to make it trivial to get it back
again.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] log4j transition
Posted by Andy McBride <an...@dsl.pipex.com>.
> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: 20 January 2006 00:05
> To: 'Jakarta Commons Developers List'
> Subject: RE: [logging] log4j transition
> From memory the problem is the inverting of the Priority and Level
> classes. In 1.2, Priority extends Level while in 1.3 Level was to extend
> Priority or somesuch. This works in a compatible manner for most
> methods, but not the Logger.log(FQDN, level, msg, t) method - which JCL
> uses. That's from memory many months old now, so may not be 100%
> correct.
I think a couple weeks ago Level was 'restored' to extend Priority whereas
it had been made a top level class before so maybe the problem has gone
away.
>
> I discussed this issue with them last year and they were determined to
> push on with their plan. They do have to get rid of the old stuff
> eventually, but it's very interesting that they are now considering
> holding off on that until a 2.0 release. I'll try to find time to talk
> to them about that but I don't think it affects the proposed JCL 1.1
> release.
No affect on JCL 1.1 at all, +1 to that.
Just hopeful that you won't need a 1.1.x release of JCL just to support
log4j1.3 when it is released :-)
Regards
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] log4j transition
Posted by Simon Kitching <sk...@apache.org>.
On Thu, 2006-01-19 at 23:27 +0000, Andy McBride wrote:
> The log4j team now appear intent on restoring binary compatibility in the
> 1.3 codebase and are attempting to defer breaking changes to a later 2.0
> release.
Thanks for the info.
> I'm not sure which incompatible changes in log4j forced you to implement the
> Log4J13Logger class but I wondered if they could now be resolved there,
> negating any future problem with using JCL1.1.x with log4j1.3 ?
>>From memory the problem is the inverting of the Priority and Level
classes. In 1.2, Priority extends Level while in 1.3 Level was to extend
Priority or somesuch. This works in a compatible manner for most
methods, but not the Logger.log(FQDN, level, msg, t) method - which JCL
uses. That's from memory many months old now, so may not be 100%
correct.
I discussed this issue with them last year and they were determined to
push on with their plan. They do have to get rid of the old stuff
eventually, but it's very interesting that they are now considering
holding off on that until a 2.0 release. I'll try to find time to talk
to them about that but I don't think it affects the proposed JCL 1.1
release.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [logging] log4j transition
Posted by Andy McBride <an...@dsl.pipex.com>.
Hi,
> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: 19 January 2006 05:31
> The name-change will break any config files that explicitly specify that
> logger name. That breakage will have to occur eventually as long as the
> log4j team keep to their plan of making a binary-incompatible release.
The log4j team now appear intent on restoring binary compatibility in the
1.3 codebase and are attempting to defer breaking changes to a later 2.0
release.
> However I think we've got enough in this release without buying into
> that issue too. In addition, I hate guessing the future on this; if we
> release a Log4J13Logger class and then it doesn't work with the real
> log4j13 that would be embarrassing.
>
> Any objections to reverting to the old naming and removing Log4J13Logger
> for now? [NB: I wrote it :-].
+1
I'm not sure which incompatible changes in log4j forced you to implement the
Log4J13Logger class but I wondered if they could now be resolved there,
negating any future problem with using JCL1.1.x with log4j1.3 ?
Regards
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org