2010/12/10 Guillaume Nodet <[email protected]> > On Fri, Dec 10, 2010 at 09:34, Achim Nierbeck <[email protected]> > wrote: > > Well with logback you also have some "nice" loggers/appenders like the > one > > that zips the log-files, you would need to re implement. > > I just don't like the idea of reimplementing if it already exists and I > just > > had the feeling since everyone is going to use slf4j and logback it would > be > > a better solution. > > Yeah, it's a bit sad, but that's also the way i've been pushed too for > this very issue. > Pax-logging already includes some additional or enhanced log4j classes > (the sifting appender), a more complete property configurator ... >
I'd guess I have to add some more appenders then :) > > I guess we could do the opposite and write our own property based > configuration for logback, but we would still be incompatible (that > just mean we'd have to bump the major version). But that's a lot of > work and i'm not sure to see the benefits of it right now, meaning I > don't want to spend that much time on this issue. > > Full ACK on this one. > > On the other hand you are right, the main issue would be that there is > only > > the possibility to configure using XML. > > Since the ConfigAdmin only uses properties, would it be possible to start > > thinking about a xml based configuration as alternative for the > ConfigAdmin > > since in the enterprise world the configurations are usually handled > through > > xml files? Just a thought :) But this has basically nothing to do with > the > > pax-logging anymore. > > > > 2010/12/10 Guillaume Nodet <[email protected]> > >> > >> You mean using logback ? > >> I guess the main problem would be: > >> * logback has no property based mechanism, so using ConfigAdmin > >> would not work out of the box > >> * all current configs would be incompatible > >> Is that just for the sake of it or are you looking to some features > >> that logback has and pax-logging has not ? > >> > >> On Fri, Dec 10, 2010 at 09:20, Achim Nierbeck <[email protected]> > >> wrote: > >> > I think your proposal sounds quite good. > >> > One other thing that comes to my mind talking of pax-logging. > >> > How much hassle would it be to use the slf4j logging as the basis > >> > for pax-logging? > >> > > >> > 2010/12/10 Guillaume Nodet <[email protected]> > >> >> > >> >> I've run into several users that can't really use pax-logging because > >> >> their bundles import slf4j api 1.6.x package which is not supported > >> >> atm. > >> >> The reason it's not is because this api is not binary compatible with > >> >> 1.5.x which mean we can't really export both packages 1.5 and 1.6 > >> >> using the same real pacakge as it's currently done for 1.4.x and > >> >> 1.5.x. > >> >> > >> >> That said, the incompatibility are quite minors (see below for the > >> >> full diff) and I think the average people won't see any problems. So > >> >> we have several ways going forward: > >> >> * just use the 1.6.x api and export 1.4.x and 1.5.x at the same > >> >> time, hoping that users won't run into those incompabilities > >> >> * just use 1.6.x api and not export 1.4 or 1.5 packages > >> >> * have a separate bundle exporting the 1.6.x api (and have it wired > >> >> correctly with pax-logging) > >> >> * move 1.5.x package into a separate bundle and use 1.6.x as the > >> >> current > >> >> api > >> >> > >> >> I suppose most of bundles using the slf4j api would use either an > open > >> >> version range such as [1.6,+oo) or a major version range [1.6,2) so I > >> >> suppose even if we go #3 or #4, it won't actually help people a lot, > >> >> so i'm tempted to go #2 and if there are any problems reported, go #4 > >> >> and force people to either upgrade to slf4j 1.6 or use a stricter > >> >> version range (in which case, we wouldn't really need #4 anymore). > >> >> > >> >> Thoughts ? > >> >> > >> >> gnodet:~/work/japidiff/target$ diff slf4j-api-1.5.11.txt > >> >> slf4j-api-1.6.0.txt > >> >> 157a158,167 > >> >> > public class FormattingTuple { > >> >> > public static org.slf4j.helpers.FormattingTuple NULL; > >> >> > public FormattingTuple(String); > >> >> > public FormattingTuple(String, Object[], Throwable); > >> >> > public Object[] getArgArray(); > >> >> > public String getMessage(); > >> >> > public Throwable getThrowable(); > >> >> > } > >> >> > > >> >> > package org.slf4j.helpers; > >> >> 196,198c206,208 > >> >> < public static final String arrayFormat(String, Object[]); > >> >> < public static final String format(String, Object); > >> >> < public static final String format(String, Object, Object); > >> >> --- > >> >> > public static final org.slf4j.helpers.FormattingTuple > >> >> > arrayFormat(String, Object[]); > >> >> > public static final org.slf4j.helpers.FormattingTuple > >> >> > format(String, > >> >> > Object); > >> >> > public static final org.slf4j.helpers.FormattingTuple > >> >> > format(String, > >> >> > Object, Object); > >> >> 239,240c249,256 > >> >> < public class NOPMakerAdapter implements org.slf4j.spi.MDCAdapter { > >> >> < public NOPMakerAdapter(); > >> >> --- > >> >> > public class NOPLoggerFactory implements org.slf4j.ILoggerFactory { > >> >> > public NOPLoggerFactory(); > >> >> > public org.slf4j.Logger getLogger(String); > >> >> > } > >> >> > > >> >> > package org.slf4j.helpers; > >> >> > public class NOPMDCAdapter implements org.slf4j.spi.MDCAdapter { > >> >> > public NOPMDCAdapter(); > >> >> 259,260c275,276 > >> >> < public static final void reportFailure(String); > >> >> < public static final void reportFailure(String, Throwable); > >> >> --- > >> >> > public static final void report(String); > >> >> > public static final void report(String, Throwable); > >> >> 270c286 > >> >> < void log(org.slf4j.Marker, String, int, String, Throwable); > >> >> --- > >> >> > void log(org.slf4j.Marker, String, int, String, Object[], > >> >> > Throwable); > >> >> > >> >> > >> >> -- > >> >> Cheers, > >> >> Guillaume Nodet > >> >> ------------------------ > >> >> Blog: http://gnodet.blogspot.com/ > >> >> ------------------------ > >> >> Open Source SOA > >> >> http://fusesource.com > >> >> > >> >> _______________________________________________ > >> >> general mailing list > >> >> [email protected] > >> >> http://lists.ops4j.org/mailman/listinfo/general > >> > > >> > > >> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
