logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Unckel" <boris.unckel....@gmx.net>
Subject Re: JULI proposal
Date Sun, 25 Sep 2005 20:27:16 GMT
Good evening,

thanks for your reply. I was watching out for any reaction and
happy that someone takes a look at it.
I hope I understood the questions correctly and the answers hit the point.

Curt Arnold 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.
There were several discussions of features (i.E. i18n logging) on log4j-dev
or commons-dev but not of the package as provided. So you did not miss 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.
- the "J"ava."U"til."L"ogging "I"mplementation does _not_
implement the API as described in JSR-47 or implemented as in J2E 1.4+. It
just adds features to the existing API.
- The initial start has been taken in the Tomcat project with
two files:
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/juli/src/java/org/apache/juli/
- Most other files have been taken from log4j. This is documented in
each file, except test sources where sometime were original author
information in log4j and sometimes not. I decided to remove any author
information. Again: All files are correctly under the Apache License,
some because they were in the past, some because they are new and
I (as author) put them under the Apache License.

In summary I had no time (in other words, I did not take the time) to
write an manual with an introduction. Currently documentation is
spreaded over project proposal and API Doc.

>
> What is the source of the initial submission?  Do you have clear  rights
to donate the code to Apache Software Foundation?  
There is no code taken from other sources than originally Apache (Jakarta)
sources.
Do you have  a Contributor's License Agreement
(http://www.apache.org/licenses) on  file?
If I understand the question right: No, I did not sign an agreement on paper
and send it to the Apache Foundation. I will do this if needed.
I am neither developer, nor committer, nor contributor in current terms.
Yes, I have the rights, through clear origin of code or due to my rights
to the new code.

>
> Do you think that the code would need to go through the Incubator 
(http://incubator.apache.org)
Yes. As I understand the process, one has to provide several things,
but one has not to provide all that tasks at once.
Hopefully some people will help me to success working on the checklists.
As I stated - I am looking for a "sandbox" (like Jakarta Commons), you
call it "incubator". By the way - what is the difference?

>
> 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?
It does not having any dependency on the GNU Classpath project.
If they want to use it, they have to fullfill the Apache Licence.

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?
JULI is an add-on to the current JDK/JRE implementation. It uses features
which are provided by the JDK developers to interact with the system.
For example you can set the 
java.util.logging.manager system property to use an non-JDK-LogManager.
"At startup the LogManager class is located using the
java.util.logging.manager system property."
(Taken from
http://java.sun.com/j2se/1.4.2/docs/api/java/util/logging/LogManager.html)
This means _using_ the system not replacing it.
JULI does _not_ rely on any bootclassing tricks or patching rt.jar.

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

There are two optional (and for the beta state of SLF4J experimental)
classes which implement SLF4J interface. If not wanted or if these classes
are a show stopper they can be removed without any dependency to the rest of
JULI. I mentioned them to show the possibilities, not the needs.

>
> Is JULI an acronym?  If so, what is the full name?
Java Util Logging Implementation. The name was invented on the log4j-dev
mailing list in march/april 2005. Please do not fix me on the date, I have
to look this up.

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

I am a developer not a solution manager or salesman. Please have a look
at the sources before you judge.
JULI addresses needs where people want to use java.util.logging and
have some features (appenders in log4j -> handlers in juli, layout in log4j
-> formatter in juli, filter -> filter) of log4j.

JULI is neither replacement of java.util.logging nor has it the full scope
of features and utilities of log4j.

Regards
Boris

Mime
View raw message