Yes, that's what I try to say more or less. TomEE doesn't change Tomcat that much (just allows to switch backend more easily hacking LogFactory to be concrete). Main issue is slf4j, log4j2 etc...doesn't have a setup which can work for app "de facto" as JUL has with the famous system properties set by default by tomcat scripts/tooling.
There is no magic logging solution and we can't find a unique framework too - I didn't search but I'm sure I can find as much thread on this topic as active developpers. That's why (almost) all lib have this custom pluggability solution. Think JCS should just allow it and make it configurable either with a property in ccf or a system property. No? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-08-20 18:46 GMT+02:00 Mark Thomas <ma...@apache.org>: > On 20/08/2014 15:41, Romain Manni-Bucau wrote: >> trying to make it complete: >> >> Solutions are: >> 1) [logging] - think it is deprecated too >> 2) log4j2: not integrated at all with anything so a bit early but we >> *need* to be compatible >> 3) slf4j: broken in hierarchical classloaders >> 4) JUL: not that friendly but prod ready in tomcat/tomee > > JUL is also totally broken in hierarchical class loaders. It only works > in Tomcat because of a custom LogManager. I assume Tomee does something > similar. > >> 5) custom logging solution: not a standard but exists in >> containers/frameworks >> 6) JCS logger facade >> >> >> I'd love to go with log4j2 by default byt I'm sure it will break in a >> lot of environment. >> Regarding TomEE use case (this issue popped up from tomee initially): >> log4j2 is not yet fully supported cause PropertyConfigurator is now a >> noop implementation and some shutdown messages were lost last time I >> re-tried (I pan to dig into it next month more or less) >> >> Personally I'd go with JUL since it is library free and can be easily >> extended to support slf4j/log4j - see >> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/logger/ >> - etc (done in cxf, OWB, OpenEJB....) but having a light JCS facade >> (mainly a factory) would work too. >> >> PS for who didnt read the associated jira: I don't want this task to >> prevent a 2.0 release. If you see it as a blocker we can do a >> 2.0-alpha but we really need to make this code released IMHO, I really >> want to avoid some tunnel effect. >> >> >> >> >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> >> 2014-08-20 16:22 GMT+02:00 David Green <djg2...@gmail.com>: >>> +1 for slf4j >>> >>> >>> >>> On 20 August 2014 14:54, Yogesh Rao <yog...@gmail.com> wrote: >>> >>>> Though i am not a member of the dev team :-) I would support a full fledge >>>> facade implementation which doesn't provide any logging at all and let the >>>> framework user decide which logging would he would like to bind it to. >>>> SLF4J does that very neatly and its also easy, i am also aware it might >>>> turn down the performance a little. >>>> >>>> Regards, >>>> -Yogesh >>>> >>>> >>>> On Wed, Aug 20, 2014 at 7:17 PM, sebb <seb...@gmail.com> wrote: >>>> >>>>> On 20 August 2014 14:37, Gary Gregory <garydgreg...@gmail.com> wrote: >>>>>> On Wed, Aug 20, 2014 at 9:28 AM, sebb <seb...@gmail.com> wrote: >>>>>> >>>>>>> On 20 August 2014 14:04, Gary Gregory <garydgreg...@gmail.com> wrote: >>>>>>>> Moving discussion about logging from [JCS-122] to this dev ML. >>>>>>>> >>>>>>>> Why not use Log4j 2, uses can redirect logging to other frameworks >>>> if >>>>>>>> needed. >>>>>>> >>>>>>> Why not use Commons Logging, can redirect logging to other frameworks >>>> if >>>>>>> needed? >>>>>>> >>>>>> >>>>>> I'd like to think that Commons Logging has been deprecated by Log4j 2 >>>> can >>>>> >>>>> That is not an opinion that is universally shared. >>>>> >>>>>> do the same thing (in principle) AND provide it's own advanced logging >>>>>> framework. >>>>> >>>>> s/it's/its/ >>>>> >>>>> That may be so, but I don't think that is sufficient reason to choose >>>>> Log4j2 over any other library. >>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> -- >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>> <http://www.manning.com/bauer3/> >>>>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>> Home: http://garygregory.com/ >>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> Java Persistence with Hibernate, Second Edition >>>>>> <http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>> Blog: http://garygregory.wordpress.com >>>>>> Home: http://garygregory.com/ >>>>>> Tweet! http://twitter.com/GaryGregory >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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
