On Wed, 2005-06-22 at 21:55 +0200, Dennis Lundberg wrote:
> Simon Kitching wrote:
> > Hi,
> >
> > Currently the Log4JLogger code in svn has this horrible stuff all
> > through it:
> > if (is12) {
> > ...
> > } else {
> > ...
> > }
> >
> > This is to handle the fact that log4j versions 1.2 and 1.3 are expected
> > to be binary incompatible in both directions, ie code compiled against
> > 1.2 won't work against 1.3 and code compiled against 1.3 won't work
> > against 1.2.
> >
> > The hack does allow code compiled against 1.3 to run against 1.3.
> > However there are a number of disadvantages:
> > * it requires compiling against 1.3 which isn't released yet
> > and may be many months away.
> > * it has a performance hit
> > * it isn't very readable
> > * it isn't future proof; when log4j 1.3 comes out, this code
> > won't work as the Priority class will go away completely.
> >
> > I would therefore prefer to split this class into separate Log4J12Logger
> > and Log4J13Logger. A static initializer block in each will check which
> > version of log4j is available, and throw an exception to declare
> > themself "unavailable" if the wrong log4j version is present. Both
> > adapters can also be included in the list of discoverable logging
> > classes.
>
> I think it would be a wise move to split the class in two. A while back
> I spent a fair amount of time trying to understand the differences
> betwen log4j 1.2 and 1.3 and also to get commons-logging to work with
> both log4j versions. It was confusing to say the least, and splitting
> this class would at least make the commons-logging code more understandable.
+1
> > Of course removing a class will mean a 1.1 version number, but that's
> > good for a number of reasons.
> >
> > The only other major concern I see is config files or system properties
> > that explicitly request the old logadapter by name. But that should be
> > easily fixable, and a config change seems a reasonable thing to do in
> > a .x release to me. Alternatively we could provide a trivial Log4JLogger
> > class that just extends Log4J12Logger; however I suspect this will cause
> > more pain and confusion than simply reporting a failure, esp. when log4j
> > 1.3 is released and starts to become widely used.
>
> I agree that, unless people have extended Log4JLogger, the only problems
> that could arise for users of commons-logging would be to change their
> config-files.
>
> If we hold on to the Log4JLogger class for a while and let it extend
> Log4J12Logger, as you suggest, we might get away with doing a 1.0.X release.
i think that the next release should be a 1.1 release in any case.
however, i would prefer retaining Log4JLogger so that it can be properly
deprecated.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
