On Wed, 2005-06-29 at 21:58 +1200, Simon Kitching wrote:
> > > The breakage is more when people refer to it in config files. Or
> > > possible call
> > > LogFactory.setAttribute(...,
> > >"org.apache.commons.logging.impl.Log4JLogger");
> >
> > that's the point: i was wondering whether we
On Tue, 2005-06-28 at 22:32 +0100, robert burrell donkin wrote:
> > The problem is that people won't be referring to it in the normal way,
> > via an import in their code (at least it's *theoretically* possible, but
> > I can't imagine anyone actually subclassing Log4JLogger.
>
> IMHO we should ha
On Mon, 2005-06-27 at 11:22 +1200, Simon Kitching wrote:
> On Sun, 2005-06-26 at 20:56 +0100, robert burrell donkin wrote:
>
> > 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.
>
> The
On Sun, 2005-06-26 at 20:56 +0100, robert burrell donkin wrote:
> 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.
The problem is that people won't be referring to it in the normal way,
via
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 versi
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
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
