On 1 December 2014 at 18:17, Christian Grobmeier <c...@grobmeier.de> wrote: > On Mon, Dec 1, 2014, at 18:04, sebb wrote: >> On 1 December 2014 at 09:28, Christian Grobmeier <grobme...@gmail.com> >> wrote: >> > That aside, I would do the following: >> > >> > - jdk support for at least >7 (varargs need 5, but MessageFormat 7) > > Just saw MessageFormat is even available in jdk 5. So I would opt for > this one. > >> -1 if this means that CL no longer works on earlier versions of Java. > > -1? haha come on, what versions would you like to support? :) Jdk 1.3 is > dead. And 1.4.2 is dead too. We speak of a CL 2.0 version, it must be > allowed to work with more recent jdks. I can't even install that old > versions on my mac. If you want to block any innovation then keep that > approach of supporting 1.3.
I did not say it needed to continue to support 1.3. > Spring needs Java 6, unarchived Tomcat versions require Java >5. Exactly. The post to which I replied implied that CL would require Java 7+ That is what I was vetoing. > We can discuss Java 5, but I am definitely not doing anything when I > need to install a vm to test with 1.3. I never wrote that. >> > - remove AvalonLogger and LogKitLogger >> >> Why? >> >> AFAIK they just work, so why drop them? > > Why keeping them? The frameworks are dead for ages Because they are still used, and they still work. Just because a product is in the Attic does not stop it working. > , it's unlikely users of Avalon might ever tend to upgrade to CL 2.0. If the MessageFormat were implemented and supported by Avalon, then it is quite possible that users would upgrade. > Of course, if you would > implement these methods for that frameworks, you are welcome. > > You need touch them to implement the new logging methods. Not necessarily; it depends where the formatting is done. > Cheers > Christian > >> >> > >> >> >> >> > For anything more I would point to log4j 2. >> >> > >> >> > Gary >> >> > >> >> > <div>-------- Original message --------</div><div>From: Christian >> >> > Grobmeier <grobme...@gmail.com> </div><div>Date:11/30/2014 16:27 >> >> > (GMT-05:00) </div><div>To: Commons Developers List >> >> > <dev@commons.apache.org> </div><div>Cc: </div><div>Subject: [logging] >> >> > Commons Logging 2.0? </div><div> >> >> > </div>Hi folks, >> >> > >> >> > I am perfectly aware that I was saying CL needs to be deprecated only >> >> > before month. >> >> > Tomcat uses CL and that was more or less the reason it would stay - so I >> >> > thought. >> >> > Recently I talked to a person actively involved in Spring. He explained, >> >> > Spring would use >> >> > CL and they are quite happy with it. Reason: it's always the same. >> >> > >> >> > He also told me that - rather having a new JSR with new interfaces which >> >> > would be difficult to get into the JDK - he would love to have some kind >> >> > of CL 2.0. >> >> > >> >> > To be honest, it made me think and reconsider whatever I have thought or >> >> > said in the past. I know Mark did say similar things, but maybe it is >> >> > the power of a direct conversation. >> >> > >> >> > I am still unsure if a CL 2.0 would be needed or not and thats why I >> >> > outreach here to ask for your feelings/opinions whatever. >> >> > >> >> > We have a Log4j2 which is really good. We have a slf4j which is fine. >> >> > And we have a CL 1.x which is, well dated. >> >> > >> >> > Would it make sense to have a CL 2.0 which is more or less (maybe with >> >> > small adjustments, despite the major version jump) a drop in >> >> > replacement? It could just add some methods or things like variable >> >> > substitutions, and thats it. Nothing big. Modern JVM support, some more >> >> > methods. The rest all the same, except log4j 2 support (which is also >> >> > provided by the log4j project). >> >> > >> >> > As mentioned I am still undecided. But CL 2.0 could be a minimal >> >> > interface for consumers looking for stability instead of tons of >> >> > features. However a bit more "modern taste" doesn't hurt, as long as it >> >> > doesn't break things (too much). >> >> > >> >> > Thoughts? >> >> > >> >> > Christian >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
