Wolf,
Problem) 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? Solution) In your new project make sure that you only use the Logger and Level classes, never referring directly to Category and Priority classes or instances. When and if the Category and Priority classes are removed in a future version of log4j, you will not be affected. Here is a slightly more complicated version of the same: Problem) My company is considering adopting log4j as its logging framework in a new project which depends on product X which also depends on log4j version 1.1. 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. Solution) In your new project make sure that you only use the Logger and Level classes, never referring directly to Category and Priority classes or instances. As for product X, since it is based on log4j 1.1, unless product X uses a subclass of Category, it will also run with log4j version 1.2. Assuming product X is actively maintained, it is likely that product X will gradually replace references to Category class with references to Logger. Developers have ample time to perform the change. Assuming product X is updated to only use the Logger class, when and if the Category and Priority classes are removed in a future version of log4j, you will not be affected. The key factor here is time. Eventually, the vast majority of applications will be based on log4j 1.2 and later versions. In say 2004, very few people will be using older log4j versions, especially in light of strong deprecation warnings. At 12:52 11.06.2002 +0200, [EMAIL PROTECTED] wrote: >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.htmlunun -- 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
