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 Jacob Kjome <ho...@visi.com> on 2005/07/09 22:34:14 UTC
Log4j 1.2.xx and 1.3 binary compatibility
I've been trying to use LogWeb with Log4j-1.3. I found a few fundamental
things that need to be changed in order to allow this to happen (those done
and checked in, marked as such)...
1. (done) RendererMap is missing the following method...
static public void addRenderer(RendererSupport repository, String
renderedClassName, String renderingClassName) {}
2. the Filter class made variables private where they were public before
and added getter/setter methods. See
http://issues.apache.org/bugzilla/show_bug.cgi?id=35654 . This probably
requires us to add getter/setter methods to a 1.2.xx release (1.2.12).
3. Now that ErrorHandler's are no longer used in 1.3, the Interface and
the two implementations that Log4j-1.2.xx ships with (OnlyOnceErrorHandler
and FallbackErrorHandler) are gone and the Appender interface no longer has
get/set methods for ErrorHandler. This is a problem both for users having
config files with error handlers listed and for LogWeb which accesses the
Appender API to get/set error handlers. I have actually put these back in
place in my local sandbox and have LogWeb up and running with a local build
of Log4j-1.3! I just wanted to make sure that committing these changes is
ok. Thoughts? The idea would be that a future version, post 1.3, would
remove ErrorHandler's altogether (2.0?). OnlyOnceErrorHandler and
FallbackErrorHandler would be put back in place, but with the methods being
entirely NOP and the setter on the Appenders being NOP's. Thoughts? Opinions?
With this in place, I think we should be mostly binary compatible with
Log4j-1.2.xx (at least with 1.2.12).
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Log4j 1.2.xx and 1.3 binary compatibility
Posted by Mark Womack <wo...@adobe.com>.
Well, I thought it was just using Logger for that class. I guess you can
look at code where LogLog was replaced. I'd have to look myself to be sure.
Sorry,
-Mark
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Monday, July 11, 2005 1:12 PM
> To: Log4J Developers List; womack@adobe.com
> Subject: RE: Log4j 1.2.xx and 1.3 binary compatibility
>
> Quoting Mark Womack <wo...@adobe.com>:
>
> > Jake, thanks for looking into all this. I think #3 is fine. Those
> classes
> > should report some kind of warning when their methods are called, and
> > configurators should be changed to report warnings when those classes
> are
> > used in configuration files. This will give users of 1.3 the idea that
> > something has changed and needs to be looked at. If you could do this,
> that
> > would be great.
> >
>
> I can do it. Just wondering what I should use to output the warning?
> getLogger() isn't always available and LogLog is deprecated. I'm at work
> and
> not looking at the code ATM, so I can't give any specifics right now.
> But, in
> general, what would be the proper way to output this deprecation
> information?
>
> > These are the kinds of things we need for checking 1.3. I know we have
> made
> > a lot of big changes in 1.3, but having it mostly work out of the box
> with
> > 1.2 installations is pretty important. The work that you and Curt are
> doing
> > in this regard is great.
> >
>
> Well, mostly Curt, but thanks!
>
> Jake
>
> > Thanks,
> > -Mark
> >
> > > -----Original Message-----
> > > From: Jacob Kjome [mailto:hoju@visi.com]
> > > Sent: Saturday, July 09, 2005 1:34 PM
> > > To: Log4J Developers List
> > > Subject: Log4j 1.2.xx and 1.3 binary compatibility
> > >
> > >
> > > I've been trying to use LogWeb with Log4j-1.3. I found a few
> fundamental
> > > things that need to be changed in order to allow this to happen (those
> > > done
> > > and checked in, marked as such)...
> > >
> > > 1. (done) RendererMap is missing the following method...
> > >
> > > static public void addRenderer(RendererSupport repository, String
> > > renderedClassName, String renderingClassName) {}
> > >
> > > 2. the Filter class made variables private where they were public
> before
> > > and added getter/setter methods. See
> > > http://issues.apache.org/bugzilla/show_bug.cgi?id=35654 . This
> probably
> > > requires us to add getter/setter methods to a 1.2.xx release (1.2.12).
> > >
> > > 3. Now that ErrorHandler's are no longer used in 1.3, the Interface
> and
> > > the two implementations that Log4j-1.2.xx ships with
> (OnlyOnceErrorHandler
> > > and FallbackErrorHandler) are gone and the Appender interface no
> longer
> > > has
> > > get/set methods for ErrorHandler. This is a problem both for users
> having
> > > config files with error handlers listed and for LogWeb which accesses
> the
> > > Appender API to get/set error handlers. I have actually put these
> back in
> > > place in my local sandbox and have LogWeb up and running with a local
> > > build
> > > of Log4j-1.3! I just wanted to make sure that committing these
> changes is
> > > ok. Thoughts? The idea would be that a future version, post 1.3,
> would
> > > remove ErrorHandler's altogether (2.0?). OnlyOnceErrorHandler and
> > > FallbackErrorHandler would be put back in place, but with the methods
> > > being
> > > entirely NOP and the setter on the Appenders being NOP's. Thoughts?
> > > Opinions?
> > >
> > >
> > > With this in place, I think we should be mostly binary compatible with
> > > Log4j-1.2.xx (at least with 1.2.12).
> > >
> > >
> > > Jake
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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: Log4j 1.2.xx and 1.3 binary compatibility
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Mark Womack <wo...@adobe.com>:
> Jake, thanks for looking into all this. I think #3 is fine. Those classes
> should report some kind of warning when their methods are called, and
> configurators should be changed to report warnings when those classes are
> used in configuration files. This will give users of 1.3 the idea that
> something has changed and needs to be looked at. If you could do this, that
> would be great.
>
I can do it. Just wondering what I should use to output the warning?
getLogger() isn't always available and LogLog is deprecated. I'm at work and
not looking at the code ATM, so I can't give any specifics right now. But, in
general, what would be the proper way to output this deprecation information?
> These are the kinds of things we need for checking 1.3. I know we have made
> a lot of big changes in 1.3, but having it mostly work out of the box with
> 1.2 installations is pretty important. The work that you and Curt are doing
> in this regard is great.
>
Well, mostly Curt, but thanks!
Jake
> Thanks,
> -Mark
>
> > -----Original Message-----
> > From: Jacob Kjome [mailto:hoju@visi.com]
> > Sent: Saturday, July 09, 2005 1:34 PM
> > To: Log4J Developers List
> > Subject: Log4j 1.2.xx and 1.3 binary compatibility
> >
> >
> > I've been trying to use LogWeb with Log4j-1.3. I found a few fundamental
> > things that need to be changed in order to allow this to happen (those
> > done
> > and checked in, marked as such)...
> >
> > 1. (done) RendererMap is missing the following method...
> >
> > static public void addRenderer(RendererSupport repository, String
> > renderedClassName, String renderingClassName) {}
> >
> > 2. the Filter class made variables private where they were public before
> > and added getter/setter methods. See
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=35654 . This probably
> > requires us to add getter/setter methods to a 1.2.xx release (1.2.12).
> >
> > 3. Now that ErrorHandler's are no longer used in 1.3, the Interface and
> > the two implementations that Log4j-1.2.xx ships with (OnlyOnceErrorHandler
> > and FallbackErrorHandler) are gone and the Appender interface no longer
> > has
> > get/set methods for ErrorHandler. This is a problem both for users having
> > config files with error handlers listed and for LogWeb which accesses the
> > Appender API to get/set error handlers. I have actually put these back in
> > place in my local sandbox and have LogWeb up and running with a local
> > build
> > of Log4j-1.3! I just wanted to make sure that committing these changes is
> > ok. Thoughts? The idea would be that a future version, post 1.3, would
> > remove ErrorHandler's altogether (2.0?). OnlyOnceErrorHandler and
> > FallbackErrorHandler would be put back in place, but with the methods
> > being
> > entirely NOP and the setter on the Appenders being NOP's. Thoughts?
> > Opinions?
> >
> >
> > With this in place, I think we should be mostly binary compatible with
> > Log4j-1.2.xx (at least with 1.2.12).
> >
> >
> > Jake
> >
> >
> > ---------------------------------------------------------------------
> > 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: Log4j 1.2.xx and 1.3 binary compatibility
Posted by Simon Kitching <sk...@apache.org>.
Hi,
While on this subject of binary compatiblity, are you aware of the
existence of CLIRR (clirr.sourceforge.net)?
This tool can generate a report on the binary compatibility of two
versions of a library. Here's a report generated by comparing
log4j-1.2.9.jar and log4j-1.3alpha-6.jar:
http://people.apache.org/~skitching/log4j-1.2.9-to-1.3alpha-6-diff.txt
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: Log4j 1.2.xx and 1.3 binary compatibility
Posted by Mark Womack <wo...@adobe.com>.
Jake, thanks for looking into all this. I think #3 is fine. Those classes
should report some kind of warning when their methods are called, and
configurators should be changed to report warnings when those classes are
used in configuration files. This will give users of 1.3 the idea that
something has changed and needs to be looked at. If you could do this, that
would be great.
These are the kinds of things we need for checking 1.3. I know we have made
a lot of big changes in 1.3, but having it mostly work out of the box with
1.2 installations is pretty important. The work that you and Curt are doing
in this regard is great.
Thanks,
-Mark
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Saturday, July 09, 2005 1:34 PM
> To: Log4J Developers List
> Subject: Log4j 1.2.xx and 1.3 binary compatibility
>
>
> I've been trying to use LogWeb with Log4j-1.3. I found a few fundamental
> things that need to be changed in order to allow this to happen (those
> done
> and checked in, marked as such)...
>
> 1. (done) RendererMap is missing the following method...
>
> static public void addRenderer(RendererSupport repository, String
> renderedClassName, String renderingClassName) {}
>
> 2. the Filter class made variables private where they were public before
> and added getter/setter methods. See
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35654 . This probably
> requires us to add getter/setter methods to a 1.2.xx release (1.2.12).
>
> 3. Now that ErrorHandler's are no longer used in 1.3, the Interface and
> the two implementations that Log4j-1.2.xx ships with (OnlyOnceErrorHandler
> and FallbackErrorHandler) are gone and the Appender interface no longer
> has
> get/set methods for ErrorHandler. This is a problem both for users having
> config files with error handlers listed and for LogWeb which accesses the
> Appender API to get/set error handlers. I have actually put these back in
> place in my local sandbox and have LogWeb up and running with a local
> build
> of Log4j-1.3! I just wanted to make sure that committing these changes is
> ok. Thoughts? The idea would be that a future version, post 1.3, would
> remove ErrorHandler's altogether (2.0?). OnlyOnceErrorHandler and
> FallbackErrorHandler would be put back in place, but with the methods
> being
> entirely NOP and the setter on the Appenders being NOP's. Thoughts?
> Opinions?
>
>
> With this in place, I think we should be mostly binary compatible with
> Log4j-1.2.xx (at least with 1.2.12).
>
>
> Jake
>
>
> ---------------------------------------------------------------------
> 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