|
|
|
Arjohn Kampman
|
Hi all,
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. Regards, Arjohn Kampman -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396497 |
||||||||||||||||
|
Rhett Sutphin
|
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 Rhett ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396499 |
||||||||||||||||
|
Tal Liron
|
I use slf4j in my Restlet applications with much success. It will likely
not be added to Restlet's distribution, but there's no reason why you can't do it on your own. Perhaps someone can write a "recipe" for how to do this on the Restlet wiki? No, I'm not volunteering myself. :) -Tal On 09/18/2009 10:37 AM, 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 > > Rhett > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396499 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396501 |
||||||||||||||||
|
Rhett Sutphin
|
Hi Tal,
On Sep 18, 2009, at 10:57 AM, Tal Liron wrote: > I use slf4j in my Restlet applications with much success. It will > likely > not be added to Restlet's distribution, but there's no reason why you > can't do it on your own. > > Perhaps someone can write a "recipe" for how to do this on the Restlet > wiki? No, I'm not volunteering myself. :) There already is one, way down at the bottom of the page Jerome linked to in that other thread: http://wiki.restlet.org/docs_1.2/13-restlet/48-restlet/101-restlet.html I have had no joy getting this to work in Tomcat (I tried putting it in a ServletContextListener), but I also haven't tried very hard. Rhett > > -Tal > > On 09/18/2009 10:37 AM, 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 >> >> Rhett >> >> ------------------------------------------------------ >> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396499 >> > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396501 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2396505 |
||||||||||||||||
|
Arjohn Kampman
|
In reply to this post
by Rhett Sutphin
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=2396548 |
||||||||||||||||
|
jlouvel
|
Hi Arjohn,
Beside the simplicity of requiring a single JAR (important), the size concern (minor indeed), the licensing aspect (with a multi-license scheme for Restlet), 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). If performance through JULI+SLF4J is really bad, maybe you chould look at a direct bridge from JULI to the logging framework you selected? 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? 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:[hidden email]] Envoyé : vendredi 18 septembre 2009 19:13 À : [hidden email] 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 |
||||||||||||||||
|
Rhett Sutphin
|
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:[hidden email]] > Envoyé : vendredi 18 septembre 2009 19:13 > À : [hidden email] > 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 |
||||||||||||||||
|
eshepelyuk
|
Hello,
I won't not adding too much value into the discussion, but just my 2 cents. Using JUL is really really painful. Before we've migrated our logging to SLF4F + JUL bridge + logback as backend we used boilerpate code to configure restlet's logging programmatically (since it's only framework we are using that is JUL dependent). Now with SLF4J it became fun :) So from pain and fun my choice is fun :) SLF4J worked in several our restlet-based project and until now we don't see issues. My post is just my 2 cents and nothing really valuable for making decisions :) > 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:[hidden email]] >> Envoyé : vendredi 18 septembre 2009 19:13 >> À : [hidden email] >> 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 > -- Regards, Evgeny Shepelyuk ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402392 |
||||||||||||||||
|
jlouvel
|
Hi all,
Evgeny, thanks for sharing your experience. I find this post very valuable actually. Rhett, the single JAR choice is useful IMHO for new users, to convince them that Restlet is truly lightweight. Then, they learn to progressively add extensions and dependencies without feeling forced to do so. As you pointed out, some of the technical reasons are not much relevant in SLF4J case due to its nature. But, I'm a bit stubborn on this one, sorry :) However, I do think it is possible to achieve something similar to SLF4JBridgeHandler, without the cost of creating the LogRecord instances. This would be possible because instead of providing a JULI Handler, we could provide a special JULI Logger for SLF4J. As we control the creation of our Restlet loggers, we don't have to catch all records of all JULI loggers like the SLF4J bridge has to do. Instead of doing Logger.getLogger(loggerName), we could do Engine.getLogger(loggerName) and this would return either a regular JULI Logger or a direct SLF4J logger wrapper. We could then provide a way in the Restlet engine to register a different logger factory. 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 : news [mailto:[hidden email]] De la part de Evgeny Shepelyuk Envoyé : jeudi 1 octobre 2009 09:34 À : [hidden email] Objet : Re: logging framework for restlet Hello, I won't not adding too much value into the discussion, but just my 2 cents. Using JUL is really really painful. Before we've migrated our logging to SLF4F + JUL bridge + logback as backend we used boilerpate code to configure restlet's logging programmatically (since it's only framework we are using that is JUL dependent). Now with SLF4J it became fun :) So from pain and fun my choice is fun :) SLF4J worked in several our restlet-based project and until now we don't see issues. My post is just my 2 cents and nothing really valuable for making decisions :) > 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:[hidden email]] >> Envoyé : vendredi 18 septembre 2009 19:13 >> À : [hidden email] >> 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 > -- Regards, Evgeny Shepelyuk ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402392 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402480 |
||||||||||||||||
|
Patrick Logan-3
|
"the single JAR choice is useful IMHO for new users, to convince them that Restlet is truly lightweight. Then, they learn to progressively add extensions and dependencies without feeling forced to do so"
I agree. I am not a new user to restlet, but this continues to be a key feature for my own use, and for promoting it with other folks. My various projects have expanded out to use other extensions. But I appreciate being able to drop a single jar somewhere and start using all the basic features without any hassle on something quick. ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402637 |
||||||||||||||||
|
Arjohn Kampman
|
In reply to this post
by jlouvel
Hi Jerome,
Thanks for keeping an open mind to changes. Jerome Louvel wrote: [...] > However, I do think it is possible to achieve something similar to > SLF4JBridgeHandler, without the cost of creating the LogRecord > instances. This would be possible because instead of providing a JULI > Handler, we could provide a special JULI Logger for SLF4J. As we > control the creation of our Restlet loggers, we don't have to catch > all records of all JULI loggers like the SLF4J bridge has to do. > > Instead of doing Logger.getLogger(loggerName), we could do > Engine.getLogger(loggerName) and this would return either a regular > JULI Logger or a direct SLF4J logger wrapper. > > We could then provide a way in the Restlet engine to register a > different logger factory. I think this option would solve the problem, at least for me. There's one other option that I thought up: restlet could switch to slf4j for logging and distribute a core jar-file ("restlet-slf4j") without a specific logging implementation. Developers can that use the slf4j mechanism to pick the logging implementation of their choice. As Rhett already indicated, this means at least three jar-files will be required for running restlets. To address this concern, an additional restlet jar that includes the slf4j API as well as the slf4j-jdk14 binding could be created. Considering that slf4j has a BSD-license, I don't see any issues with that. Since this would be backwards compatible with the existing org.restlet jar, keeping that name would be a good option, IMHO. Regards, Arjohn ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402679 |
||||||||||||||||
|
Arjohn Kampman
|
Hi all,
Any developments or ideas wrt logging? Regards, Arjohn Arjohn Kampman wrote: > Hi Jerome, > > Thanks for keeping an open mind to changes. > > Jerome Louvel wrote: > [...] >> However, I do think it is possible to achieve something similar to >> SLF4JBridgeHandler, without the cost of creating the LogRecord >> instances. This would be possible because instead of providing a JULI >> Handler, we could provide a special JULI Logger for SLF4J. As we >> control the creation of our Restlet loggers, we don't have to catch >> all records of all JULI loggers like the SLF4J bridge has to do. >> >> Instead of doing Logger.getLogger(loggerName), we could do >> Engine.getLogger(loggerName) and this would return either a regular >> JULI Logger or a direct SLF4J logger wrapper. >> >> We could then provide a way in the Restlet engine to register a >> different logger factory. > > I think this option would solve the problem, at least for me. > > There's one other option that I thought up: restlet could switch to > slf4j for logging and distribute a core jar-file ("restlet-slf4j") > without a specific logging implementation. Developers can that use the > slf4j mechanism to pick the logging implementation of their choice. > > As Rhett already indicated, this means at least three jar-files will > be required for running restlets. To address this concern, an additional > restlet jar that includes the slf4j API as well as the slf4j-jdk14 > binding could be created. Considering that slf4j has a BSD-license, I > don't see any issues with that. Since this would be backwards compatible > with the existing org.restlet jar, keeping that name would be a good > option, IMHO. > > Regards, > > Arjohn > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2402679 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2408851 |
||||||||||||||||
|
jlouvel
|
Hi Arjohn,
I finally found time to work on my latest suggestion. I've just checked in SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on JULI by default. There is also a new "org.restlet.ext.slf4j" extension which provides a Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra creation of LogRecord instances). It can be set with a system property. See updated documentation on the wiki: http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html Let me know how it works! 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:[hidden email]] Envoyé : lundi 19 octobre 2009 08:45 À : [hidden email] Objet : Re: logging framework for restlet Hi all, Any developments or ideas wrt logging? Regards, Arjohn Arjohn Kampman wrote: > Hi Jerome, > > Thanks for keeping an open mind to changes. > > Jerome Louvel wrote: > [...] >> However, I do think it is possible to achieve something similar to >> SLF4JBridgeHandler, without the cost of creating the LogRecord >> instances. This would be possible because instead of providing a JULI >> Handler, we could provide a special JULI Logger for SLF4J. As we >> control the creation of our Restlet loggers, we don't have to catch >> all records of all JULI loggers like the SLF4J bridge has to do. >> >> Instead of doing Logger.getLogger(loggerName), we could do >> Engine.getLogger(loggerName) and this would return either a regular >> JULI Logger or a direct SLF4J logger wrapper. >> >> We could then provide a way in the Restlet engine to register a >> different logger factory. > > I think this option would solve the problem, at least for me. > > There's one other option that I thought up: restlet could switch to > slf4j for logging and distribute a core jar-file ("restlet-slf4j") > without a specific logging implementation. Developers can that use the > slf4j mechanism to pick the logging implementation of their choice. > > As Rhett already indicated, this means at least three jar-files will > be required for running restlets. To address this concern, an additional > restlet jar that includes the slf4j API as well as the slf4j-jdk14 > binding could be created. Considering that slf4j has a BSD-license, I > don't see any issues with that. Since this would be backwards compatible > with the existing org.restlet jar, keeping that name would be a good > option, IMHO. > > Regards, > > Arjohn > > ------------------------------------------------------ > 79 -- Arjohn Kampman, Senior Software Engineer Aduna - Semantic Power www.aduna-software.com ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24088 51 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2412667 |
||||||||||||||||
|
Tal Liron
|
Small mistake in the wiki:
It says: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLogFacade But it should be: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLoggerFacade Jerome, this is a small but very considerate addition to Restlet. It's always good to see how you listen to what users want. Thanks! -Tal On 10/29/2009 09:36 AM, Jerome Louvel wrote: > Hi Arjohn, > > I finally found time to work on my latest suggestion. I've just checked in > SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on > JULI by default. > > There is also a new "org.restlet.ext.slf4j" extension which provides a > Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra > creation of LogRecord instances). It can be set with a system property. > > See updated documentation on the wiki: > http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html > > Let me know how it works! > > 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:[hidden email]] > Envoyé : lundi 19 octobre 2009 08:45 > À : [hidden email] > Objet : Re: logging framework for restlet > > Hi all, > > Any developments or ideas wrt logging? > > Regards, > > Arjohn > > > Arjohn Kampman wrote: > >> Hi Jerome, >> >> Thanks for keeping an open mind to changes. >> >> Jerome Louvel wrote: >> [...] >> >>> However, I do think it is possible to achieve something similar to >>> SLF4JBridgeHandler, without the cost of creating the LogRecord >>> instances. This would be possible because instead of providing a JULI >>> Handler, we could provide a special JULI Logger for SLF4J. As we >>> control the creation of our Restlet loggers, we don't have to catch >>> all records of all JULI loggers like the SLF4J bridge has to do. >>> >>> Instead of doing Logger.getLogger(loggerName), we could do >>> Engine.getLogger(loggerName) and this would return either a regular >>> JULI Logger or a direct SLF4J logger wrapper. >>> >>> We could then provide a way in the Restlet engine to register a >>> different logger factory. >>> >> I think this option would solve the problem, at least for me. >> >> There's one other option that I thought up: restlet could switch to >> slf4j for logging and distribute a core jar-file ("restlet-slf4j") >> without a specific logging implementation. Developers can that use the >> slf4j mechanism to pick the logging implementation of their choice. >> >> As Rhett already indicated, this means at least three jar-files will >> be required for running restlets. To address this concern, an additional >> restlet jar that includes the slf4j API as well as the slf4j-jdk14 >> binding could be created. Considering that slf4j has a BSD-license, I >> don't see any issues with that. Since this would be backwards compatible >> with the existing org.restlet jar, keeping that name would be a good >> option, IMHO. >> >> Regards, >> >> Arjohn >> >> ------------------------------------------------------ >> >> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24026 > 79 > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2412891 |
||||||||||||||||
|
jlouvel
|
Hi Tal,
Thanks for your support and for reporting the typo (now fixed)! 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 : Tal Liron [mailto:[hidden email]] Envoyé : vendredi 30 octobre 2009 03:37 À : [hidden email] Objet : Re: logging framework for restlet Small mistake in the wiki: It says: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLogFacade But it should be: org.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLoggerFacade Jerome, this is a small but very considerate addition to Restlet. It's always good to see how you listen to what users want. Thanks! -Tal On 10/29/2009 09:36 AM, Jerome Louvel wrote: > Hi Arjohn, > > I finally found time to work on my latest suggestion. I've just checked in > SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on > JULI by default. > > There is also a new "org.restlet.ext.slf4j" extension which provides a > Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra > creation of LogRecord instances). It can be set with a system property. > > See updated documentation on the wiki: > http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html > > Let me know how it works! > > 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:[hidden email]] > Envoyé : lundi 19 octobre 2009 08:45 > À : [hidden email] > Objet : Re: logging framework for restlet > > Hi all, > > Any developments or ideas wrt logging? > > Regards, > > Arjohn > > > Arjohn Kampman wrote: > >> Hi Jerome, >> >> Thanks for keeping an open mind to changes. >> >> Jerome Louvel wrote: >> [...] >> >>> However, I do think it is possible to achieve something similar to >>> SLF4JBridgeHandler, without the cost of creating the LogRecord >>> instances. This would be possible because instead of providing a JULI >>> Handler, we could provide a special JULI Logger for SLF4J. As we >>> control the creation of our Restlet loggers, we don't have to catch >>> all records of all JULI loggers like the SLF4J bridge has to do. >>> >>> Instead of doing Logger.getLogger(loggerName), we could do >>> Engine.getLogger(loggerName) and this would return either a regular >>> JULI Logger or a direct SLF4J logger wrapper. >>> >>> We could then provide a way in the Restlet engine to register a >>> different logger factory. >>> >> I think this option would solve the problem, at least for me. >> >> There's one other option that I thought up: restlet could switch to >> slf4j for logging and distribute a core jar-file ("restlet-slf4j") >> without a specific logging implementation. Developers can that use the >> slf4j mechanism to pick the logging implementation of their choice. >> >> As Rhett already indicated, this means at least three jar-files will >> be required for running restlets. To address this concern, an additional >> restlet jar that includes the slf4j API as well as the slf4j-jdk14 >> binding could be created. Considering that slf4j has a BSD-license, I >> don't see any issues with that. Since this would be backwards compatible >> with the existing org.restlet jar, keeping that name would be a good >> option, IMHO. >> >> Regards, >> >> Arjohn >> >> ------------------------------------------------------ >> >> > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=24026 > 79 > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2412891 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2413722 |
||||||||||||||||
|
Arjohn Kampman
|
In reply to this post
by jlouvel
Hi Jerome,
Some feedback as promised: I am now setting the system property in the class that creates and starts the Component. Routing log request works like a charm in this setup. For users the prefer a simple war-file we're also offering an alternative using the ServerServlet wrapper. I don't know yet how to reroute the logging in this case. ServerServlet works on an Application so the Engine likely already has been initialized by the time the Application class is created. It's too late to set the system property then. Any suggestions? Arjohn Arjohn Kampman wrote: > Hi Jerome, > > Many thanks. I'll have a look at this as soon as possible and let you > know the results. > > Arjohn > > Jerome Louvel wrote: >> Hi Arjohn, >> >> I finally found time to work on my latest suggestion. I've just >> checked in >> SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on >> JULI by default. >> >> There is also a new "org.restlet.ext.slf4j" extension which provides a >> Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra >> creation of LogRecord instances). It can be set with a system property. >> >> See updated documentation on the wiki: >> http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html >> >> Let me know how it works! >> >> Best regards, >> Jerome Louvel ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2420041 |
||||||||||||||||
|
Thierry Boileau
|
Hello Arjohn,
as a quick workaround, you can inherit from the ServerServlet and override the "init" method. Then, register your own ServerServlet class in the web.xml configuration file: <servlet-class>my.package.MyServerServlet</servlet-class> Best regards, Thierry Boileau > Hi Jerome, > > Some feedback as promised: > > I am now setting the system property in the class that creates and > starts the Component. Routing log request works like a charm in this > setup. > > For users the prefer a simple war-file we're also offering an > alternative using the ServerServlet wrapper. I don't know yet how to > reroute the logging in this case. ServerServlet works on an Application > so the Engine likely already has been initialized by the time the > Application class is created. It's too late to set the system property > then. > > Any suggestions? > > Arjohn > > > Arjohn Kampman wrote: > >> Hi Jerome, >> >> Many thanks. I'll have a look at this as soon as possible and let you >> know the results. >> >> Arjohn >> >> Jerome Louvel wrote: >> >>> Hi Arjohn, >>> >>> I finally found time to work on my latest suggestion. I've just >>> checked in >>> SVN trunk a new org.restlet.engine.log.LoggerFacade class which relies on >>> JULI by default. >>> >>> There is also a new "org.restlet.ext.slf4j" extension which provides a >>> Slf4jLoggerFacade acting as an optimal bridge to SLF4J API (without extra >>> creation of LogRecord instances). It can be set with a system property. >>> >>> See updated documentation on the wiki: >>> http://wiki.restlet.org/docs_2.0/13-restlet/48-restlet/101-restlet.html >>> >>> Let me know how it works! >>> >>> Best regards, >>> Jerome Louvel >>> > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2420041 > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2420442 |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |