JULI proposal

[Curt Arnold <ca...@apache.org>]

This is in regards to recently filed bug 36805 (http:// 
issues.apache.org/bugzilla/show_bug.cgi?id=36805).  If there has been  
any previous discussion, I have missed it.

All this information may be in attachments to the bug, but it would  
be helpful to me if you provide some essential background information.

What is the source of the initial submission?  Do you have clear  
rights to donate the code to Apache Software Foundation?  Do you have  
a Contributor's License Agreement (http://www.apache.org/licenses) on  
file?

Do you think that the code would need to go through the Incubator  
(http://incubator.apache.org)

How does this relate to GNU Classpath (http://www.gnu.org/software/ 
classpath/) which provides independent clean-room implementations of  
core class libraries and appears to implement java.util.logging?  The  
GNU Classpath implementations take great care avoid potential legal  
issues (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)  
that we don't encounter.

How would conflicts between the JDK provided implementation of  
java.util.logging and JULI be resolved?

SLF4J is not an Apache project and having an Apache product depend on  
a non-ASF project is undesirable.  What is the nature of the  
dependency on SLF4J?

Is JULI an acronym?  If so, what is the full name?

My initial reaction is that there are too many legal and licensing  
issues to justify the project in light of only vague outlined benefits.

Re: JULI proposal

[Yoav Shapira <yo...@apache.org>]

Hi,

> I want to understand what niche JULI is filling here.  It extends the jdk 
> logging but uses log4j classes and implements JCL and SLF4J interfaces?  Why 
> would I want to use this instead of log4j or the jdk libraries?

You may not, and a normal user may not, but the container developer (Tomcat
being the container here) does.  The reason is to gradually reduce dependence
on JCL, which has been mostly a nightmare, inside the container itself, and
migrate towards the smallest possible container implementation that is still
under Tomcat's own control but not an area where significant maintanance work
needs to be done.  The motivation for this is a couple of years of PITA with
complicated bugs related to JCL, log4j, servlet classloaders, and the
interaction thereof, plus volatility with things like SLF4J and JCL 2.0, plus
the fact Tomcat 5.5 now requires JDK 1.4 so built-in logging is easily
available.

Please keep in mind I'm not exactly advocating this: I didn't write a bit of
JULI, but I do understand the frustrations that have led to it.  And I have to
say, logging-related bugs and complaints amongst the tomcat-user community have
dropped significantly since its introduction.

Yoav

Re: JULI proposal

[Mark Womack <mw...@apache.org>]

I want to understand what niche JULI is filling here.  It extends the jdk 
logging but uses log4j classes and implements JCL and SLF4J interfaces?  Why 
would I want to use this instead of log4j or the jdk libraries?

My mind is open, but it lacks information and background here.

WRT specifics about incubator, etc...I think that the above should be 
addressed first, then we can look at full subproject vs sandbox, etc.  To be 
a full subproject there would need to be a community built up around it and 
it would probably need to go through incubator (as part of that process). 
If the effort is warranted and there is interest, then we can look at it.

But we need to understand it all first.

thanks,
-Mark

----- Original Message ----- 
From: "Yoav Shapira" <yo...@apache.org>
To: "Logging General" <ge...@logging.apache.org>
Sent: Sunday, September 25, 2005 3:01 PM
Subject: Re: JULI proposal


> Hi,
> Besides agreeding with Curt's concerns, this seems unnecessary.  Why do 
> it?
> Introducing yet another set of names, interfaces, classes is unlikely to 
> be
> well-received...
>
> Yoav
>
> --- Curt Arnold <ca...@apache.org> wrote:
>
>> This is in regards to recently filed bug 36805 (http://
>> issues.apache.org/bugzilla/show_bug.cgi?id=36805).  If there has been
>> any previous discussion, I have missed it.
>>
>> All this information may be in attachments to the bug, but it would
>> be helpful to me if you provide some essential background information.
>>
>> What is the source of the initial submission?  Do you have clear
>> rights to donate the code to Apache Software Foundation?  Do you have
>> a Contributor's License Agreement (http://www.apache.org/licenses) on
>> file?
>>
>> Do you think that the code would need to go through the Incubator
>> (http://incubator.apache.org)
>>
>> How does this relate to GNU Classpath (http://www.gnu.org/software/
>> classpath/) which provides independent clean-room implementations of
>> core class libraries and appears to implement java.util.logging?  The
>> GNU Classpath implementations take great care avoid potential legal
>> issues (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)
>> that we don't encounter.
>>
>> How would conflicts between the JDK provided implementation of
>> java.util.logging and JULI be resolved?
>>
>> SLF4J is not an Apache project and having an Apache product depend on
>> a non-ASF project is undesirable.  What is the nature of the
>> dependency on SLF4J?
>>
>> Is JULI an acronym?  If so, what is the full name?
>>
>> My initial reaction is that there are too many legal and licensing
>> issues to justify the project in light of only vague outlined benefits.
>>
>>
>>
>
> 

Re: JULI proposal

[Yoav Shapira <yo...@apache.org>]

Hi,
Besides agreeding with Curt's concerns, this seems unnecessary.  Why do it? 
Introducing yet another set of names, interfaces, classes is unlikely to be
well-received...

Yoav

--- Curt Arnold <ca...@apache.org> wrote:

> This is in regards to recently filed bug 36805 (http:// 
> issues.apache.org/bugzilla/show_bug.cgi?id=36805).  If there has been  
> any previous discussion, I have missed it.
> 
> All this information may be in attachments to the bug, but it would  
> be helpful to me if you provide some essential background information.
> 
> What is the source of the initial submission?  Do you have clear  
> rights to donate the code to Apache Software Foundation?  Do you have  
> a Contributor's License Agreement (http://www.apache.org/licenses) on  
> file?
> 
> Do you think that the code would need to go through the Incubator  
> (http://incubator.apache.org)
> 
> How does this relate to GNU Classpath (http://www.gnu.org/software/ 
> classpath/) which provides independent clean-room implementations of  
> core class libraries and appears to implement java.util.logging?  The  
> GNU Classpath implementations take great care avoid potential legal  
> issues (http://www.gnu.org/software/classpath/faq/faq.html#faq3_2)  
> that we don't encounter.
> 
> How would conflicts between the JDK provided implementation of  
> java.util.logging and JULI be resolved?
> 
> SLF4J is not an Apache project and having an Apache product depend on  
> a non-ASF project is undesirable.  What is the nature of the  
> dependency on SLF4J?
> 
> Is JULI an acronym?  If so, what is the full name?
> 
> My initial reaction is that there are too many legal and licensing  
> issues to justify the project in light of only vague outlined benefits.
> 
> 
>