Hi Jerome, On Sep 30, 2009, at 5:23 AM, Jerome Louvel wrote:
> Beside the simplicity of requiring a single JAR (important), This is a reasonable concern -- if you used SLF4J in restlet core, you'd go from 1 JAR to (at least) 3 JARs (restlet, slf4j-api, and an slf4j implementation). However, I wonder how many restlet users actually only use the core. Have you ever done a survey? > the size > concern (minor indeed), the licensing aspect (with a multi-license > scheme > for Restlet), SLF4J is MIT licensed: http://slf4j.org/license.html . > the 'zero dependency rule' is also helpful when we support > Restlet editions like GWT/GAE or Android where an external > dependency might > not work seamlessly (not sure about SLF4J though). I haven't tried using SLF4J in any of those environments (though I found evidence that it will work on GAE[1]), but the core SLF4J code is really, really simple. [1]: http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html > If performance through JULI+SLF4J is really bad, maybe you chould > look at a > direct bridge from JULI to the logging framework you selected? The performance issue that Arjohn brought up is on the JUL side, not on the SLF4J side. > Another option would be for Restlet to provide a simple pluggable > logging > mechanism that would use JULI API for levels, logger, etc. and JULI > 'engine' > as the default implementation. But the implementation could be > replaced > through dynamic detection of SLF4J for example. Would that be a better > solution? Dynamic detection sounds a lot like Jakarta commons-logging. JCL introduces all sorts of classloading issues -- JCL is the problem that SLF4J was designed to solve. A restlet-provided dynamic detection solution would have to be carefully designed to be OSGi compatible as well. If the concern is efficiency (and meaning no offense to you, Jerome), it seems unlikely that a restlet-provided bridge from JULI to SLF4J is going to be faster than the one provided by SLF4J itself. Rhett > BTW, I've updated the related RFE: > > "Facilitate support of alternative log mechanisms" > http://restlet.tigris.org/issues/show_bug.cgi?id=179 > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Lead developer ~ http://www.restlet.org > Noelios Technologies ~ Co-founder ~ http://www.noelios.com > > > -----Message d'origine----- > De : Arjohn Kampman [mailto:arjohn.kamp...@aduna-software.com] > Envoyé : vendredi 18 septembre 2009 19:13 > À : discuss@restlet.tigris.org > Objet : Re: logging framework for restlet > > Rhett Sutphin wrote: >> Hi Arjohn, >> >> On Sep 18, 2009, at 10:31 AM, Arjohn Kampman wrote: >> >>> I was wondering if you ever considered to use a logging framework >>> such >>> as slf4j instead of using java util logging directly. This can make >>> integration of restlet in applications that don't use JUL a lot >>> easier. >> >> I'd be in favor of this, too, but the core team is dedicated zero >> dependencies in the core of the framework. Here's a discussion from >> last March: >> >> http://markmail.org/search/?q=restlet%20slf4j#query:restlet%20slf4j >> +page:1+mid:spk4x55pegqktg2y+state:results > > Guess this has had some attention before. Thanks for the pointer. > > Reading through Jerome's comments: > >> There is also a bridge from JUL to sl4j (http://www.x4juli.org/) that >> you could leverage. > > x4juli actually works the other way around: it implements the slf4j > APIs > so you can use it as a logger in the slf4j framework. > > There is a jul-to-slf4j bridge available from slf4j.org, but that is > said to add considerable overhead to the logging: > > "Consequently, j.u.l. to SLF4J translation can seriously impact on the > cost of disabled logging statements (60 fold increase) and a > measurable > impact on enabled log statements (20% overall increase)." > -- http://slf4j.org/legacy.html > >> A main design constraint that we have is zero external dependency for >> the Restlet API/Engine beside the JRE. It is good for compactness, >> facility of deployment > > Good arguments, I would say. > >> and also because we don't want to force our users to use one logging >> mechanism over another. > > Now here's the funny thing: based on the exact(!) same argument, we > actually decided to switch from jul to slf4j. Getting jul to bridge to > slf4j seems to be non-trivial task, while the reverse is as simple as > adding the appropriate jar-file to your classpath. > > So the main question now seems to be: is this sufficient reason to add > a small (30kb) external dependency to restlet? > > -- > Arjohn > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=23965 > 48 > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2401976 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402111
