Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3EEF05A1.7020708@podval.org>
Date: Tue, 17 Jun 2003 08:12:17 -0400
From: Leonid Dubinsky <dub@podval.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
MIME-Version: 1.0
Cc: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>,
	hgomez@users.sourceforge.net
Subject: Re: Logging packaging questions
References: <1055789445.7894.47.camel@rousalka.dyndns.org>
 <20030616231456.B57837@icarus.apache.org>
In-Reply-To: <20030616231456.B57837@icarus.apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Craig R. McClanahan wrote:

 >> 1. we absolutely need removal of the log4j classpath entries
 >
 >
 > The Log4J classpath entries were remnoved prior to the 1.0.3 release of
 > Commons Logging.  What version are you working with?

Looks like we are working with 1.0.3, which was released on April the 7th;
classpath entries were removed on April the 17th, so we still have them...
We just discovered that you already removed them, so by removing them in
JPackage we'll be moving closer to the original, not further :)

 >> 2. we'd like the build-in backends split from the main jar so we can
 >> made them optional and allow people not to install them if they already
 >> have log4j or a 1.4 jvm.
 >
 >
 > In the specific case of commons-logging and Log4J, that suggestion (which
 > led to the existence of commons-logging-api.jar) has been an absolute
 > disaster.  Remember that the commons-logging library is supposed to (and
 > does, at least with 1.0.3) dynamically adapt to whether Log4J is present
 > or not.  If Log4J is not available, the default behavior will operate
 > correctly, with NO need for separating the Log4J-specific implementation
 > classes.


It is that default behavior - SimpleLog - that is the target of this separation from
the rest of the commons-logging. I think that such a separation will cause
even bigger disaster, because unconfigured log4j will be used by default,
and all logging will cease...

About commons-logging-api.jar/commons-logging.jar: it seems that one
is a superset of the other, and not a complement. I wonder why...

Also: will this separation be eliminated?

 >> 3. people have asked for further splittage of the backend glue so they
 >> can only install the parts relevant to the backend they'll actually use
 >
 >
 > As a very-very-very long time Java developer, and a primary contributor to
 > many Apache projects (including Tomcat and Struts), I strongly suggest
 > that you push back on the users asking for this -- they're not
 > understanding the real issues involved.  If we did what they want, it's
 > not really going to solve the problems they think they have.


Craig, I am the people in question :)
I did not suggest that to solve any problems I am having, but as a separation
more meaningful, IMHO, than the separation of SimpleLog from the
commons-logging APIs...
I gather you are strongly against separating glue from the interface :)
Can you please hint at what *are* the real issues involved, so that I can learn
from your experience?
Wasn't the split c-l-api/c-l such a separation (albeit not as fine-grained)?

And in general, if I have provider-based architecture where each provider
is actually a proxy/adaptor to an existing service, why must all available
adaptors be bundled with the generic interface classes, and not with the
corresponding services/adaptees - or completely unbundled?


Respectfully,

Leonid Dubinsky.

P.S. Thanks for everything, including JSF!
D.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org