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:[EMAIL PROTECTED]
> Sent: Monday, July 11, 2005 1:12 PM
> To: Log4J Developers List; [EMAIL PROTECTED]
> Subject: RE: Log4j 1.2.xx and 1.3 binary compatibility
> 
> Quoting Mark Womack <[EMAIL PROTECTED]>:
> 
> > 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:[EMAIL PROTECTED]
> > > 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to