[slf4j-dev] using slf4j, nlog4j in Eclipse RCP

[John Franey]

Ceki,

Thanks for your response.  My answers to your questions are inline.

John

Ceki Gülcü wrote:

>
> Hello John,
>
> You are obviously a few steps ahead of me. I'll try to answer when I 
> can, and ask questions otherwise.
>
> More in line.
>
> At 09:07 PM 11/22/2005, John Franey wrote:
>
>> Hi,
>>
>> I've created a logging prototype in the Eclipse rich client platform 
>> using slf4j and nlog4j.  I've written an article about it which is in 
>> its final draft.  I'm about to submit it to the editors of 
>> EclipseZone (http:www.eclipsezone.com), but there are some questions 
>> I'd like to ask your development team.
>
>
> I hope they accept your submission. However, regardless of their 
> decision, I suggest that you ask to keep the copyright so that you can 
> publish its contents elsewhere. In my experience, the publicity spurt 
> that an article in a magazine brings is not worth the steady diffusion 
> power of the article published on the web-pages of your project. Most 
> magazine editors (but not book editors) will let you keep the 
> copyright. In short, you license your article to the magazine but keep 
> the copyright.
>
Thanks for the advice.  I forgot all about that take.

>> In the article, Eclipse plug-ins for the slf4j class libraries are 
>> created and introduced; one plug-in for each slf4j variant.  These 
>> plug-ins are interchangeable and so allows seperation between the 
>> application and logging framework.  Also, because slf4j contains a 
>> JCL implementation, the slf4j plug-ins can support other plug-ins 
>> that use JCL.  Way cool.  Thanks for the library.
>
>
> I am not familiar with Eclipse plug-ins (except as an Eclipse user). 
> What advantages does the plug-in form SLF4J have compared to the 
> stand-alone form? I apologize if this may seem like a stupid question.
>
I don't think it is a stupid question.

Flexibility.   A plug-in developed using SLF4J as an external plug-in 
can swap between SLF4J variants (jdk, log4j, nlog4j, custom).  A plug-in 
which embeds an SLF4J library will be bound to use the corresponding 
framework.   I think an RCP developer would prefer the former plug-in, 
only because the RCP developer can chose which framework the application 
would use.

Memory/disk footprint:  If every plug-in embedded a logger library....

Runtime confusion in Eclipse:  If every plug-in with a logging library 
exported it, Eclipse would non-deterministically select one, any one, to 
satisfy another plug-ins import.

Those are main reasons.

>> First question: The name of the plug-ins incorporate the name of your 
>> organization: org.slf4j.  Is this OK?  Its a naming convention in 
>> Eclipse plug-ins; to name a plug-in after the java package that it 
>> implements.   For example, a plug-in for LOG4J logging would be 
>> called org.apache.log4j.   Also, 99.9% of the code in the plug-in 
>> originates from slf4j, not any other entity.  The only code that I 
>> provide are entries to a jar's MANIFEST.MF file.
>
>
> The SLF4J is distributed under the X11 license (see 
> http://www.slf4j.org/license.html ) which is quite permissive. In 
> short, provided that:
>
>  the copyright notice(s) and this permission notice appear in all 
> copies of
>  the  Software and  that both  the above  copyright notice(s)  and this
>  permission notice appear in supporting documentation.
>
> You should be fine.
>
>> Second question:  Its very easy for you to build and distribute your 
>> library as Eclipse plug-ins, incorporating the modifications detailed 
>> in the article.  It requires only OSGi entries in the jar file's 
>> MANIFEST.MF.  Would you be interested in doing this?
>
>
> Why not? However, as mentioned above, the advantages of distributing 
> SLF4J as Eclipse plug-ins are not entirely obvious to me :-).
>
>> Third question:  I created a plug-in for an slf4j Logger 
>> implementation over the Eclipse RCP logging framework.  I used 
>> org.slf4j in the name of the plug-in only to keep it consistent with 
>> the other plug-in names in the article.  Is that OK?  Only the 
>> Logger, LoggerFactory and binding classes are contributed by me, the 
>> rest of the code is all yours and I'd like to maintain that credit 
>> belongs to you.
>
>
> Although you do not have to, you could license the code to slf4j.org 
> so that it could distribute your code. Alternatively, you could chose 
> to distribute your code on your own.
>
I will think this over.   I currently leaning towards licensing the code 
for slf4j to distribute.  What does it mean to license the code, 
according to slf4j?  (My stupid question for the day).

>> Fourth question:  Could I contribute the slf4j on Eclipse logging to 
>> your project?  One objection you may have is that there are build 
>> time dependencies on the Eclipse RCP libraries.
>
>
> The Eclipse RCP library dependency is not a problem. In principle, 
> each binding already depends on some underlying library, e.g. log4j. 
> Dependencies on logging systems is what SLF4J is all about.
>
> Let me contact you offline for details about creating an account for 
> you, commit rights etc on the slf4j.org server.
>
>> Thanks,
>> John
>
>