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. 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 >
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
