logging framework for restlet

17 messages Options
Embed this post
Permalink
Arjohn Kampman

logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

RE: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

RE: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

RE: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
"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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

RE: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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


--
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

RE: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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

Re: logging framework for restlet

Reply Threaded More More options
Print post
Permalink
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