I think John's issue is more general. Here is a sample scenario:
  My company is considering adopting log4j as its logging framework in a
  new project.  We are deploying our code on the application server foo 
  which is already using log4j for logging.
  New versions of foo may come with new versions of log4j. Is it
  guaranteed that our binary code will run with all new versions of log4j?
Anwering with an unqualified yes would mean to guarantee that the public 
API of *all* log4j classes won't change anymore (except for extensions). 
IMHO that would be a too strong restriction. A possible answer could be:
  The public Logger and Level API is guaranteed to never change anymore,
  except for extensions. Anything else may be modified in the future.
If I understood John correctly, he wants to get a commitment on binary
compatibility of some API subset, so he can be sure that when his project
restricts calls to this subset, their binary code will *never* break, 
regardless of the log4j version it happens to run with.

Wolf

> -----Ursprüngliche Nachricht-----
> Von: Ceki Gülcü [mailto:[EMAIL PROTECTED]] 
> Gesendet: Dienstag, 11. Juni 2002 11:56
> An: Log4J Developers List
> Betreff: RE: Binary compatibility between versions of log4j
> 
> 
> 
> Problem definition:
> 
> My company is considering adopting log4j as its logging framework in a
> new project.  However, we are worried about the removal of the
> Category and Priority classes in future log4j releases. (The javadocs
> suggest that these classes may be removed in 2H2003.) How can we be
> sure that the removal of the Category and Priority classes will not
> break our application once it is released to our customers?
> 
> Do we agree that the above defines the problem you are facing?
> 
> At 10:38 11.06.2002 +0100, you wrote:
> >Your question is in a different tense to mine. You ask:
> >
> >"For instance, what part or parts of log4j ARE binary incompatible?"
> >
> >My question is:
> >
> >"what part or parts of log4j MAY BECOME binary incompatible?"
> >
> >At present the answer to this question is apparently "any of 
> log4j may
> >become binary incompatible". In two of your (Ceki's) 
> responses you have
> >stressed that various pieces of log4j may not become binary 
> incompatible,
> >but in saying this you seem to be very clearly reserving the 
> right to break
> >binary compatability in the future. I want to know if there is any
> >possibility that your position on this point will change.
> >
> >I have made every attempt to define the problem clearly - if 
> you tell me the
> >points I am being vague on I will be happy to clarify them.
> >
> >John
> >
> >--
> >To unsubscribe, e-mail:   
> <mailto:log4j-dev-> [EMAIL PROTECTED]>
> >For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> --
> Ceki
> 
> SUICIDE BOMBING - A CRIME AGAINST HUMANITY
> Sign the petition: http://www.petitiononline.com/1234567b
> I am signatory number 22106. What is your number?
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:log4j-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 


--
SMS zu teuer? 50 SMS aus dem E-Mail Office versenden - und  das Monat fuer Monat!
Dazu gibt es noch 100 MB Speicherplatz fuer die Mailbox, 700 MB virtuelle Festplatte
und 50 Faxe pro Monat! Jetzt anmelden unter  
http://www.freenet.de/tipp/premium/index.html

Reply via email to