Hi Christian, one of those unlikely users of Avalon is the Turbine framework but I can lend a hand with AvalonLogger :-)
Cheers, Siegfried Goeschl > On 01 Dec 2014, at 19: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. > > Spring needs Java 6, unarchived Tomcat versions require Java >5. > We can discuss Java 5, but I am definitely not doing anything when I > need to install a vm to test with 1.3. > >>> - remove AvalonLogger and LogKitLogger >> >> Why? >> >> AFAIK they just work, so why drop them? > > Why keeping them? The frameworks are dead for ages, it's unlikely users > of Avalon might ever tend to upgrade to CL 2.0. Of course, if you would > implement these methods for that frameworks, you are welcome. > > You need touch them to implement the new logging methods. > > 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
