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
