If you want to drive into this, you may want to review the LogMF and LogSF companions and related discussion in the archives.
The cost of the array construction implicit in a vararg call and the cost of boxing scalars can dwarf the cost of determining whether to log or not. Unfortunately those activities occur unconditionally prior to determining whether the request is above the threshold. Doesn't matter much when a message goes to an appender but makes the no-op call substantially more expensive. The LogMF and LogSF companions defined a substantial number of overloads so that you'd rarely call the vararg implementation and take its performace hit. It had to target JDK 1.4 so it couldn't use templates and might be more elegantly written without that limitation. LogMF used the message format syntax but optimized the trivial string substitution case to avoid poor performance for the simple cases while it defers to the JDK implementation for the atypical cases. Resulting in performance that was indistinguishable from LogSF which used the SLF4J format specifiers while still preserving the much richer capabilities. Their should also be discussion around a LogF which would use the new at the time JDK 5 formatted bit I don't recall that much about it. It was the only means I could find to add vararg like capability to log4j 1 without breaking compatibility, but I thought it came out fairly well. Sent from my iPhone > On Dec 1, 2014, at 3:15 PM, Siegfried Goeschl <siegfried.goes...@it20one.com> > wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
