You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ceki Gülcü <ce...@qos.ch> on 2002/05/10 15:06:32 UTC
Resisting the temptation
Greetings to all,
As most of you are probably aware, log4j version 1.2 final was released
just a few hours ago. One of the important planned new features of
log4j 1.3 is the capability to interpret configuration files (in XML)
with tags that were unknown at compile time. In other words, we would
like log4j to be able to learn about new tags dynamically. This
probably similar to ANT's capability of learning new tasks.
The commons-digester library offers the infrastructure to support such
capability. In short, I think commons-digester has what log4j
needs. However, commons-digester requires commons-collections,
commons-beanutils and commons-logging. Here is short list of concerns
in increasing order of importance:
1) That's log4j.jar plus 4 jars instead of just log4j.jar.
2) Commons-xxx depends on JDK 1.2 where as log4j runs with JDK 1.1.
3) Circular dependencies. Log4j depends on commons-digester, which
depends on commons-logging which depends on log4j.
Given this seemingly intractable concerns, I have asked Costin
Manolache, Craig McClanahan and Scott Sanders to borrow the
commons-digester code. They all graciously granted permission for the
modification of their code and its inclusion in log4j.
So what's problem you might ask? Well, it seems rather wasteful to
start a new code base while a perfectly good one exists already. In
other words, I am trying to resist the urge to start all over again.
Concern number 1), that is the increase in the number of jars, is a fact
of (modular) life. As for concern 2), log4j can enforce that the extensible
configuration capability requires JDK 1.2 while the rest remains JDK 1.1
compatible. Concern 3) is the one I find most challenging. There are 3
possible approaches:
1) commons-digester et al. drop the requirement for commons-logging.
2) log4j accepts to depend on commons-logging
3) some new innovative approach...
Solution 1) is probably not acceptable to the commons community.
Solution 2 is not acceptable to the log4j community. Solution 3
requires a fresh approach. Can you please help us find a solution in order to
resist the temptation?
TIA, Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 11 May 2002, Ceki Gülcü wrote:
> Date: Sat, 11 May 2002 00:24:43 +0200
> From: Ceki Gülcü <ce...@qos.ch>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: Resisting the temptation
>
> At 12:17 10.05.2002 -0700, Craig R. McClanahan wrote:
>
> > > Another, much more serious worry that I have is the fact that the
> > LogFactory
> > > class keeps track of LogFactories by classloader. What will happen in an
> > > environment with multiple classloader per application, eg. EAR classloader
> > > parent of WAR classloader, parent of JSP classloader, as is the case in
> > > WebLogic and WebSphere? Doesn't Tomcat and other Servlet containers
> > > pose the same problem, with to classloaders, the WAR classloader and
> > > the JSP classloader? Wouldn't multiple LogFactories, that is multiple
> > logging
> > > environments be loaded in a single application?
> > >
> > > What am I missing here?
> > >
> >
> >For Tomcat 4 specifically (and generically for 2.3-based servlet
> >containers), the webapp class loader is allowed to look locally first for
> >things before delegating. Thus, the current implementation in LogFactory
> >allows you to put commons-logging.jar and a logging implementation, with a
> >default logging configuration, into common/lib -- but still allow a webapp
> >to configure its own loggers differently if it wants to (either by
> >including a JAR file with the right services entry in WEB-INF/lib, or by
> >including a commons-logging.properties file in WEB-INF/classes). Per-JSP
> >class loaders (if the container uses them) will have the webapp class
> >loader as the parent, so these JSP pages will see the same logging
> >configuration.
>
> I did not know that the 2-3 spec allowed changes to the classloading
> delegation
> model. Is it nevertheless accurate to say that each classloader even within
> the same application will have its own LogFactory implemenation?
>
Yes.
> >Craig
>
> --
> Ceki
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by robert burrell donkin <ro...@mac.com>.
i don't think that forking a separate version of digester for use by log4j
by replacing the references to commons-logging is going to be necessarily
an easy or maintainable solution. it's not just a new version of digester
that you're going to need - you'll also need to create and maintain forks
of collections and beanutils.
i had bowed out (hopefully gracefully) of the commons-logging development/
debate but i suppose i should say at least something...
in terms of trying to wangle some way of forcing the commons-logging
configuration so that the Log4jFactory is used, i really don't see how
feeding back log messages about problems in the log4j configuration back
into log4j is going to cause anything but grief all round. i'd have
thought that a special logging implementation (controlled by log4j) is
needed that knows how to deal with logging messages posted whilst log4j is
trying to configure itself.
it might be possible to resolve this issue by making the digester log
creation lazy (so that a digester instance can be created before the logs
are initialized) and by making the LogFactory implementation used to
create the logs a variable (which could be set by either a constructor or
a property) rather than relying on the static default. of course, the
default LogFactory would default to being the default. (doh!)
when log4j created a digester instance for use with parsing it's
configuration, it could set the LogFactory to be used to it's own custom
class that knows how to cope with logging messages created during log4j
configuration.
of course if we go for this approach, beanutils and collections would also
need to be changed to follow this logging strategy.
(i'm mightily sick of worthless logging flame wars. i've had my say now
and i'm going to crawl back under the stone from whence i came. so you'll
be wasting your time trying to engage me in debate. if you don't like this
idea - why not be positive for once and come up with a better solution?)
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Ceki Gülcü <ce...@qos.ch>.
At 12:17 10.05.2002 -0700, Craig R. McClanahan wrote:
> > Another, much more serious worry that I have is the fact that the
> LogFactory
> > class keeps track of LogFactories by classloader. What will happen in an
> > environment with multiple classloader per application, eg. EAR classloader
> > parent of WAR classloader, parent of JSP classloader, as is the case in
> > WebLogic and WebSphere? Doesn't Tomcat and other Servlet containers
> > pose the same problem, with to classloaders, the WAR classloader and
> > the JSP classloader? Wouldn't multiple LogFactories, that is multiple
> logging
> > environments be loaded in a single application?
> >
> > What am I missing here?
> >
>
>For Tomcat 4 specifically (and generically for 2.3-based servlet
>containers), the webapp class loader is allowed to look locally first for
>things before delegating. Thus, the current implementation in LogFactory
>allows you to put commons-logging.jar and a logging implementation, with a
>default logging configuration, into common/lib -- but still allow a webapp
>to configure its own loggers differently if it wants to (either by
>including a JAR file with the right services entry in WEB-INF/lib, or by
>including a commons-logging.properties file in WEB-INF/classes). Per-JSP
>class loaders (if the container uses them) will have the webapp class
>loader as the parent, so these JSP pages will see the same logging
>configuration.
I did not know that the 2-3 spec allowed changes to the classloading
delegation
model. Is it nevertheless accurate to say that each classloader even within
the same application will have its own LogFactory implemenation?
>Craig
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 13 May 2002, Ceki Gülcü wrote:
> Date: Mon, 13 May 2002 23:09:14 +0200
> From: Ceki Gülcü <ce...@qos.ch>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: Resisting the temptation
>
> At 12:17 10.05.2002 -0700, Craig McClanahan wrote:
>
> >For Tomcat 4 specifically (and generically for 2.3-based servlet
> >containers), the webapp class loader is allowed to look locally first for
> >things before delegating. Thus, the current implementation in LogFactory
> >allows you to put commons-logging.jar and a logging implementation, with a
> >default logging configuration, into common/lib -- but still allow a webapp
> >to configure its own loggers differently if it wants to (either by
> >including a JAR file with the right services entry in WEB-INF/lib, or by
> >including a commons-logging.properties file in WEB-INF/classes). Per-JSP
> >class loaders (if the container uses them) will have the webapp class
> >loader as the parent, so these JSP pages will see the same logging
> >configuration.
>
> Per Section 9.7.2 (last paragraph) of the spec 2.3. Thanks for the light...
> On the other hand, doesn't the current classloading implementation(s) of
> Tomcat give precedence to whatever is in common/lib/, common/classes,
> or jre/lib/ext/?
>
For review, the class loader hierarchy in a standard Tomcat 4 environment
(i.e. you use the standard scripts to start it) is as follows:
Bootstrap (could be several depending on JVM. Includes jre/lib/ext)
|
|
|
System (the CLASSPATH that is set up by catalina.sh/catalina.bat)
|
|
|
Common (common/classes and common/lib)
/ \
/ \
/ \
Catalina Shared (classes and lib in 4.0,
(server/classes \ shared/classes and shared/lib in 4.1)
server/lib) \
\
Webapp (WEB-INF/classes and WEB-INF/lib)
All of these class loaders, *except* the Webapp class loader, follow the
standard Java delegation model. In effect, that means that the class
loaders are searched from the top of the tree down to the class loader you
originally asked to load a class for you (i.e. if you've got a class in
the shared class loader, and you say "new Foo()", it searches Bootstrap,
System, Common, and Shared in that order for Foo.class).
The webapp class loader is the exception to the rule -- it searches
locally (in WEB-INF/classes and WEB-INF/lib) first, and only *then* goes
to the top of the list and works back down. There are protections built
in to the class loader implementation to avoid security problems like
spoofing a java.* or javax.servlet.* class.
The answer to which classes (for ClassLoader.loadClass()) and resources
(for ClassLoader.getResource() and ClassLoader.getResourceAsStream()) are
given preference depends, first of all, on which class loader you use to
do the lookup. If you put commons-logging.jar into the common class
loader (as a default 4.1 build does), then the normal process would look
only in Bootstrap, System, and Common for configuration information.
However, the J2EE/1.3 (which means servlet 2.3) servlet containers are
also required to make the webapp class loader visible to application code
running on a request processing thread (or during things like init() to a
servlet), via a call to:
Thread.currentThread().getContextClassLoader()
(Although 2.2 containers are not required to support this, most of them in
fact do so as well.)
The commons-logging factory search algorithm takes advantage of this to
ask the webapp class loader (if one can be found) to do the configuration
resource lookup. That way, a commons-logging.properties resource (or a
META/INF/services entry in a JAR file) that is inside the webapp will
still take precedence (for that webapp only) over anything configured in
common/lib.
> >Craig
>
>
> --
> Ceki
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Ceki Gülcü <ce...@qos.ch>.
At 12:17 10.05.2002 -0700, Craig McClanahan wrote:
>For Tomcat 4 specifically (and generically for 2.3-based servlet
>containers), the webapp class loader is allowed to look locally first for
>things before delegating. Thus, the current implementation in LogFactory
>allows you to put commons-logging.jar and a logging implementation, with a
>default logging configuration, into common/lib -- but still allow a webapp
>to configure its own loggers differently if it wants to (either by
>including a JAR file with the right services entry in WEB-INF/lib, or by
>including a commons-logging.properties file in WEB-INF/classes). Per-JSP
>class loaders (if the container uses them) will have the webapp class
>loader as the parent, so these JSP pages will see the same logging
>configuration.
Per Section 9.7.2 (last paragraph) of the spec 2.3. Thanks for the light...
On the other hand, doesn't the current classloading implementation(s) of
Tomcat give precedence to whatever is in common/lib/, common/classes,
or jre/lib/ext/?
>Craig
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 10 May 2002, Ceki Gülcü wrote:
> Date: Fri, 10 May 2002 20:43:45 +0200
> From: Ceki Gülcü <ce...@qos.ch>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: Resisting the temptation
>
> At 13:17 10.05.2002 -0400, Geir Magnusson Jr. wrote:
>
> >The real problem is the digester dependency on logging, isn't it?
>
> It's one of the problems, perhaps the most interesting one but not
> the only one. Other problems are the increase in the number of
> necessary jar files, JDK compatibility issues and most importantly
> the increase in complexity of the logging setup.
>
> >A solution I can think of is for log4j to have a services entry in their
> >jar's META-INF to be the logger factory for logging.
>
> This is in line with Craig's suggestion about setting Log4jFactory
> in
>
> 1) META-INF/services/org.apache.commons.logging.LogFactory"
>
> 2) org.apache.commons.logging.LogFactory property in
> a "commons-logging.properties" file
>
> 3) org.apache.commons.logging.LogFactory in the system
> properties
>
> I think at the least the first 2 are needed because
> we might not be running under JDK 1.3.
>
Because the search algorithm is implemented inside
LogFactory.getFactory(), it's not dependent on JDK 1.3. -- The
META-INF/services search will work on any JDK.
>
> One simple question that pops up to my mind is the what
> will happen if for another jar does the same, for example
> logkit. It would be quite hilarious to have internal log4j
> messages to be output by logkit. :-)
>
:-)
If such a thing does happen, it goes back to the issue of "who's first on
the class path".
> Another, much more serious worry that I have is the fact that the LogFactory
> class keeps track of LogFactories by classloader. What will happen in an
> environment with multiple classloader per application, eg. EAR classloader
> parent of WAR classloader, parent of JSP classloader, as is the case in
> WebLogic and WebSphere? Doesn't Tomcat and other Servlet containers
> pose the same problem, with to classloaders, the WAR classloader and
> the JSP classloader? Wouldn't multiple LogFactories, that is multiple logging
> environments be loaded in a single application?
>
> What am I missing here?
>
For Tomcat 4 specifically (and generically for 2.3-based servlet
containers), the webapp class loader is allowed to look locally first for
things before delegating. Thus, the current implementation in LogFactory
allows you to put commons-logging.jar and a logging implementation, with a
default logging configuration, into common/lib -- but still allow a webapp
to configure its own loggers differently if it wants to (either by
including a JAR file with the right services entry in WEB-INF/lib, or by
including a commons-logging.properties file in WEB-INF/classes). Per-JSP
class loaders (if the container uses them) will have the webapp class
loader as the parent, so these JSP pages will see the same logging
configuration.
In a J2EE environment, per-EAR class loaders would let each enterprise
application define its own logging configuration independently, in the
same way.
> --
> Ceki
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Ceki Gülcü <ce...@qos.ch>.
At 13:17 10.05.2002 -0400, Geir Magnusson Jr. wrote:
>The real problem is the digester dependency on logging, isn't it?
It's one of the problems, perhaps the most interesting one but not
the only one. Other problems are the increase in the number of
necessary jar files, JDK compatibility issues and most importantly
the increase in complexity of the logging setup.
>A solution I can think of is for log4j to have a services entry in their
>jar's META-INF to be the logger factory for logging.
This is in line with Craig's suggestion about setting Log4jFactory
in
1) META-INF/services/org.apache.commons.logging.LogFactory"
2) org.apache.commons.logging.LogFactory property in
a "commons-logging.properties" file
3) org.apache.commons.logging.LogFactory in the system
properties
I think at the least the first 2 are needed because
we might not be running under JDK 1.3.
One simple question that pops up to my mind is the what
will happen if for another jar does the same, for example
logkit. It would be quite hilarious to have internal log4j
messages to be output by logkit. :-)
Another, much more serious worry that I have is the fact that the LogFactory
class keeps track of LogFactories by classloader. What will happen in an
environment with multiple classloader per application, eg. EAR classloader
parent of WAR classloader, parent of JSP classloader, as is the case in
WebLogic and WebSphere? Doesn't Tomcat and other Servlet containers
pose the same problem, with to classloaders, the WAR classloader and
the JSP classloader? Wouldn't multiple LogFactories, that is multiple logging
environments be loaded in a single application?
What am I missing here?
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Henri Yandell <ba...@generationjava.com>.
Heh. This is an itch of mine. I want to wrap a bunch of the Commons jar's
into a core jar, but it's a different set of jars than these. It's
something I do with my own code, and as Kurt has pointed out, as it gets
more successful it is an increasingly annoying problem.
If the issue is just, there are 4 jars versus 1 jar, then I say deal with
it. It's an inherent problem in the Java library system and hopefully a
CJAN built on one of the jar-management projects will solve that kinda
stuff.
If the issue is having log4j dependent on commons.logging, which seems a
little odd, that might require some other thunking.
Hen
On Fri, 10 May 2002, James Strachan wrote:
> Hi Ceki
>
> Anyone who uses the digester needs digester, beanutils, collections and
> logging. Its a shame there's not just a single jar for all these 4 (very
> common) things. How about we bundle these 4 things into a single 'uber-jar'?
> Say, commons-core.jar. We could maybe ensure that whenever we release one of
> these 4 jars, we release the whole bundle (commons-core) together too. Or we
> could just get jjar/maven rocking... :-)
>
> James
> ----- Original Message -----
> From: "Ceki G�lc�" <ce...@qos.ch>
> To: <co...@jakarta.apache.org>
> Sent: Friday, May 10, 2002 2:06 PM
> Subject: Resisting the temptation
>
>
> >
> > Greetings to all,
> >
> > As most of you are probably aware, log4j version 1.2 final was released
> > just a few hours ago. One of the important planned new features of
> > log4j 1.3 is the capability to interpret configuration files (in XML)
> > with tags that were unknown at compile time. In other words, we would
> > like log4j to be able to learn about new tags dynamically. This
> > probably similar to ANT's capability of learning new tasks.
> >
> > The commons-digester library offers the infrastructure to support such
> > capability. In short, I think commons-digester has what log4j
> > needs. However, commons-digester requires commons-collections,
> > commons-beanutils and commons-logging. Here is short list of concerns
> > in increasing order of importance:
> >
> > 1) That's log4j.jar plus 4 jars instead of just log4j.jar.
> >
> > 2) Commons-xxx depends on JDK 1.2 where as log4j runs with JDK 1.1.
> >
> > 3) Circular dependencies. Log4j depends on commons-digester, which
> > depends on commons-logging which depends on log4j.
> >
> > Given this seemingly intractable concerns, I have asked Costin
> > Manolache, Craig McClanahan and Scott Sanders to borrow the
> > commons-digester code. They all graciously granted permission for the
> > modification of their code and its inclusion in log4j.
> >
> > So what's problem you might ask? Well, it seems rather wasteful to
> > start a new code base while a perfectly good one exists already. In
> > other words, I am trying to resist the urge to start all over again.
> >
> > Concern number 1), that is the increase in the number of jars, is a fact
> > of (modular) life. As for concern 2), log4j can enforce that the
> extensible
> > configuration capability requires JDK 1.2 while the rest remains JDK 1.1
> > compatible. Concern 3) is the one I find most challenging. There are 3
> > possible approaches:
> >
> > 1) commons-digester et al. drop the requirement for commons-logging.
> > 2) log4j accepts to depend on commons-logging
> > 3) some new innovative approach...
> >
> > Solution 1) is probably not acceptable to the commons community.
> > Solution 2 is not acceptable to the log4j community. Solution 3
> > requires a fresh approach. Can you please help us find a solution in
> order to
> > resist the temptation?
> >
> > TIA, Ceki
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Joe Germuska <jo...@germuska.com>.
>Not having collections.jar in java.util was a transitionary thing, this
>would be a future thing in which either a subset of Commons gets named
>Core just to suit Log4J or coders have to change their code to handle a
>move from Commons-Collections to Commons-Core.
I don't think it's just to suit Log4J though. I also think it's
tedious to manage a number of different jars (sure, some tools could
improve that) -- I think you're right that the ones which map closest
to the JDK are what belong in the core, so maybe digester doesn't
belong in there.
Of course, some of the other commons packages you named aren't as
mature/well-tested as Collections and BeanUtils, but as long as high
standards were held before things moved into the core, that could be
managed.
At 9:34 AM -0500 5/10/02, Waldhoff, Rodney wrote:
> > [Concern] 3) Circular dependencies. Log4j depends on commons-digester,
>which
>> depends on commons-logging which depends on log4j.
>
>Why not split the commons-logging interface from the specific
>implementations, for example, by moving the log4j implementation of
>commons-logging into log4j itself?
This sounds more appropriate, if the Log4J community would accept it.
Joe
--
--
* Joe Germuska { joe@germuska.com }
"It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble.... As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records."
--Sam Goody, 1956
tune in posse radio: <http://www.live365.com/stations/289268>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Kurt Schrader <ks...@engin.umich.edu>.
On Fri, 10 May 2002, Henri Yandell wrote:
> Maybe the solution is to offer two types of jar:
>
> commons-collections.jar, commons-digester.jar etc
> and
> commons-all.jar.
>
> Then it will be quite obvious to a developer when they are using both.
This just encourages lazy project management. You should know what your
project depends on. Also it causes a problem if you rely on project A
which relies on commons-all.jar version 1 and project B which relies on
commons-all.jar version 2 just to use different versions of different
libraries inside. Conflicts will occur and now the onus is on you to sort
it out. Rolling a big jar is a bad idea.
-Kurt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Henri Yandell <ba...@generationjava.com>.
What do you define as Commons-Core though? To me Core means the most
generic bits of Commons. So IO/Lang/Net/Util/Collections/BeanUtils/.. In
fact anything that maps directly to the java.* libraries. Things like Digester
are to my knowledge not added functionality to the JDK, though logging
could be. So we'd have some parts of Commons declared as Core and others
as projects that if they grow big enough might leave Commons.
There's been negative views to this concept in the past though.
Not having collections.jar in java.util was a transitionary thing, this
would be a future thing in which either a subset of Commons gets named
Core just to suit Log4J or coders have to change their code to handle a
move from Commons-Collections to Commons-Core.
Maybe the solution is to offer two types of jar:
commons-collections.jar, commons-digester.jar etc
and
commons-all.jar.
Then it will be quite obvious to a developer when they are using both. A
command line cjan tool should even be in charge of keeping an eye out for
such issues. God knows how.
Hen
On Fri, 10 May 2002, Joe Germuska wrote:
> At 10:05 AM -0400 5/10/02, Kurt Schrader wrote:
> >On Fri, 10 May 2002, James Strachan wrote:
> >
> >> Anyone who uses the digester needs digester, beanutils, collections and
> >> logging. Its a shame there's not just a single jar for all these 4 (very
> >> common) things. How about we bundle these 4 things into a single 'uber-jar'?
> >> Say, commons-core.jar. We could maybe ensure that whenever we release one of
> >> these 4 jars, we release the whole bundle (commons-core) together too.
> >
> >This is a _bad_ idea. If you have commons-core and a different version
> >of one of the other jars in the same classpath, then the possibility of
> >conflicts that cause problems is extremely high. I've found that
> >having jars inside of jars is always a bad idea.
>
> This is a good point, although otherwise I think it's a good idea.
>
> Perhaps the risk of conflict could be minimized with a new package
> hierarchy like 'org.apache.commons.core'
>
> Kind of like how "collections.jar" classes were not in "java.util."
>
> Once the transition was over, it would be painless...
>
> Joe
>
> --
> --
> * Joe Germuska { joe@germuska.com }
> "It's pitiful, sometimes, if they've got it bad. Their eyes get
> glazed, they go white, their hands tremble.... As I watch them I
> often feel that a dope peddler is a gentleman compared with the man
> who sells records."
> --Sam Goody, 1956
> tune in posse radio: <http://www.live365.com/stations/289268>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Joe Germuska <jo...@germuska.com>.
At 10:05 AM -0400 5/10/02, Kurt Schrader wrote:
>On Fri, 10 May 2002, James Strachan wrote:
>
>> Anyone who uses the digester needs digester, beanutils, collections and
>> logging. Its a shame there's not just a single jar for all these 4 (very
>> common) things. How about we bundle these 4 things into a single 'uber-jar'?
>> Say, commons-core.jar. We could maybe ensure that whenever we release one of
>> these 4 jars, we release the whole bundle (commons-core) together too.
>
>This is a _bad_ idea. If you have commons-core and a different version
>of one of the other jars in the same classpath, then the possibility of
>conflicts that cause problems is extremely high. I've found that
>having jars inside of jars is always a bad idea.
This is a good point, although otherwise I think it's a good idea.
Perhaps the risk of conflict could be minimized with a new package
hierarchy like 'org.apache.commons.core'
Kind of like how "collections.jar" classes were not in "java.util."
Once the transition was over, it would be painless...
Joe
--
--
* Joe Germuska { joe@germuska.com }
"It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble.... As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records."
--Sam Goody, 1956
tune in posse radio: <http://www.live365.com/stations/289268>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Kurt Schrader <ks...@engin.umich.edu>.
On Fri, 10 May 2002, James Strachan wrote:
> Anyone who uses the digester needs digester, beanutils, collections and
> logging. Its a shame there's not just a single jar for all these 4 (very
> common) things. How about we bundle these 4 things into a single 'uber-jar'?
> Say, commons-core.jar. We could maybe ensure that whenever we release one of
> these 4 jars, we release the whole bundle (commons-core) together too.
This is a _bad_ idea. If you have commons-core and a different version
of one of the other jars in the same classpath, then the possibility of
conflicts that cause problems is extremely high. I've found that
having jars inside of jars is always a bad idea.
> Or we could just get jjar/maven rocking... :-)
Working on it. :-)
-Kurt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 5/10/02 9:17 AM, "James Strachan" <ja...@yahoo.co.uk> wrote:
> Hi Ceki
>
> Anyone who uses the digester needs digester, beanutils, collections and
> logging. Its a shame there's not just a single jar for all these 4 (very
> common) things. How about we bundle these 4 things into a single 'uber-jar'?
> Say, commons-core.jar. We could maybe ensure that whenever we release one of
> these 4 jars, we release the whole bundle (commons-core) together too. Or we
> could just get jjar/maven rocking... :-)
The real problem is the digester dependency on logging, isn't it?
A solution I can think of is for log4j to have a services entry in their
jar's META-INF to be the logger factory for logging.
geir
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Ceki
Anyone who uses the digester needs digester, beanutils, collections and
logging. Its a shame there's not just a single jar for all these 4 (very
common) things. How about we bundle these 4 things into a single 'uber-jar'?
Say, commons-core.jar. We could maybe ensure that whenever we release one of
these 4 jars, we release the whole bundle (commons-core) together too. Or we
could just get jjar/maven rocking... :-)
James
----- Original Message -----
From: "Ceki Gülcü" <ce...@qos.ch>
To: <co...@jakarta.apache.org>
Sent: Friday, May 10, 2002 2:06 PM
Subject: Resisting the temptation
>
> Greetings to all,
>
> As most of you are probably aware, log4j version 1.2 final was released
> just a few hours ago. One of the important planned new features of
> log4j 1.3 is the capability to interpret configuration files (in XML)
> with tags that were unknown at compile time. In other words, we would
> like log4j to be able to learn about new tags dynamically. This
> probably similar to ANT's capability of learning new tasks.
>
> The commons-digester library offers the infrastructure to support such
> capability. In short, I think commons-digester has what log4j
> needs. However, commons-digester requires commons-collections,
> commons-beanutils and commons-logging. Here is short list of concerns
> in increasing order of importance:
>
> 1) That's log4j.jar plus 4 jars instead of just log4j.jar.
>
> 2) Commons-xxx depends on JDK 1.2 where as log4j runs with JDK 1.1.
>
> 3) Circular dependencies. Log4j depends on commons-digester, which
> depends on commons-logging which depends on log4j.
>
> Given this seemingly intractable concerns, I have asked Costin
> Manolache, Craig McClanahan and Scott Sanders to borrow the
> commons-digester code. They all graciously granted permission for the
> modification of their code and its inclusion in log4j.
>
> So what's problem you might ask? Well, it seems rather wasteful to
> start a new code base while a perfectly good one exists already. In
> other words, I am trying to resist the urge to start all over again.
>
> Concern number 1), that is the increase in the number of jars, is a fact
> of (modular) life. As for concern 2), log4j can enforce that the
extensible
> configuration capability requires JDK 1.2 while the rest remains JDK 1.1
> compatible. Concern 3) is the one I find most challenging. There are 3
> possible approaches:
>
> 1) commons-digester et al. drop the requirement for commons-logging.
> 2) log4j accepts to depend on commons-logging
> 3) some new innovative approach...
>
> Solution 1) is probably not acceptable to the commons community.
> Solution 2 is not acceptable to the log4j community. Solution 3
> requires a fresh approach. Can you please help us find a solution in
order to
> resist the temptation?
>
> TIA, Ceki
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Ceki Gülcü <ce...@qos.ch>.
At 09:57 10.05.2002 -0700, costinm@covalent.net wrote:
> > >The downside:
> > >- I no longer believe this is the right way to configure
> > >software or deal with XML configuration :-)
> >
> > Aaaah? Can you please expand on this?
>
>There are few major problems:
>
>- reading the XML file is not enough. Log4j (for example) supports JMX,
>and that means it should be able to be confiured at runtime. You need to
>be able to persist the changes - and in the process preserve the
>structure, comments and all the elements in the config file.
>
>- scalability. What if you have a distributed application, with hundreds
>of computers in a 'farm'. You could use some scripts to copy the xml file
>on all computers, but I think it's better to be able to use LDAP or
>NDS or another directory service, which scales much better.
>
>- integration. While configuring the logger may be the center of the
>universe for log4j, most applications have dozens of components to be
>configured, and not enough time to learn the syntax of each component.
>Don't make the mistake of believing that you have a standard syntax with
>XML.
Right, XML does not give you a standard syntax. Nevertheless, XML
gives you a standard and powerful syntax for expressing information,
in this case configuration information. XML is much more expressive
than key=value files.
Isn't the *location* of XML files completely orthogonal to the issue
of XML file *contents*? On the other hand, the prefs API seems to give
you a reasonable way to express data and at the same time manage its
persistence. By the way, thanks for sharing your perspective which has
been quite thought provoking.
>Plus the fact that you end up with dozens of xml files in various
>locations. You can't combine them with namespaces - because you may have
>to write and you can only write your own piece.
>
>I think a 'preferences' API is the only sane solution. But unfortunately
>Sun again bundled util.prefs with JDK1.4 and that means it's practically
>unusable. And JNDI is far too complex for this.
If Sun's goal is to have people follow them, then they did the right
thing, at least from their stand point.
>A clone of util.prefs that can be used in any VM is ( IMHO ) the best
>solution.
>
> > >BTW, having log4j depend on commons-logging would be a huge benefit for
> > >the whole community. I know it may be hard for log4j people, but sometimes
> > >we must make painfull things.
> >
> > What would be the benefit of log4j depending on commons-logging to the
> > community? All I tend to see is more complicated bug reports and more
> > confusion on the user side. (I am afraid we have had this debate already.)
>
>A common logging API is the benfit. Yes, things may be more complicated
>and we may get more bugs - but using a single API for logging is worth it.
>You can incorporate commons-logging in the log4j distribution ( like
>xalan/xerces are doing with jaxp ), even in the same jar ( and make sure
>log4j is the default - for example by including only the log4j factory ).
With your permission, I'd like to avoid answering this one.
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by co...@covalent.net.
On Fri, 10 May 2002, Ceki Gülcü wrote:
> The down side is that jakarta would have two actively supported digesters,
> the one in commons and the one in log4j resulting in significant maintenance
> effort being wasted.
I wouldn't say XmlMapper is 'actively' supported - the code is frozen, it
does what it is supposed to do, last bug was ages ago, the performance
is good ( at least for tomcat configuration, it's no longer a 'visible'
factor ). If you can use it as is - great, if not problably it's not the
right starting point.
> >The downside:
> >- I no longer believe this is the right way to configure
> >software or deal with XML configuration :-)
>
> Aaaah? Can you please expand on this?
There are few major problems:
- reading the XML file is not enough. Log4j (for example) supports JMX,
and that means it should be able to be confiured at runtime. You need to
be able to persist the changes - and in the process preserve the
structure, comments and all the elements in the config file.
- scalability. What if you have a distributed application, with hundreds
of computers in a 'farm'. You could use some scripts to copy the xml file
on all computers, but I think it's better to be able to use LDAP or
NDS or another directory service, which scales much better.
- integration. While configuring the logger may be the center of the
universe for log4j, most applications have dozens of components to be
configured, and not enough time to learn the syntax of each component.
Don't make the mistake of believing that you have a standard syntax with
XML.
Plus the fact that you end up with dozens of xml files in various
locations. You can't combine them with namespaces - because you may have
to write and you can only write your own piece.
I think a 'preferences' API is the only sane solution. But unfortunately
Sun again bundled util.prefs with JDK1.4 and that means it's practically
unusable. And JNDI is far too complex for this.
A clone of util.prefs that can be used in any VM is ( IMHO ) the best
solution.
> >BTW, having log4j depend on commons-logging would be a huge benefit for
> >the whole community. I know it may be hard for log4j people, but sometimes
> >we must make painfull things.
>
> What would be the benefit of log4j depending on commons-logging to the
> community? All I tend to see is more complicated bug reports and more
> confusion on the user side. (I am afraid we have had this debate already.)
A common logging API is the benfit. Yes, things may be more complicated
and we may get more bugs - but using a single API for logging is worth it.
You can incorporate commons-logging in the log4j distribution ( like
xalan/xerces are doing with jaxp ), even in the same jar ( and make sure
log4j is the default - for example by including only the log4j factory ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:29 10.05.2002 -0700, you wrote:
>Hi Ceki,
>
>I can give you a quick solution - use XmlMapper from tomcat3.3.
>It's doing the same thing, works with JDK1.1, no external dependencies
>( except IntrospectionUtil - where all the real stuff happens ). It is
>quite optimized and tuned and polished.
I am not that much worried about the effort it would take to code
a digester clone, especially if the relevant authors (including yourself)
have given explicit permission to modify an existing implementation.
In short, it would take little effort to take commons-digester: change
the package names to org.apache.log4j from org.apache.commons.*,
remove unneeded Rules, remove the commons-logging references, change
the dependency on beanutils and collections and we're in business.
The down side is that jakarta would have two actively supported digesters,
the one in commons and the one in log4j resulting in significant maintenance
effort being wasted.
So while your offer to use the XmlMapper is generous, using it, is precisely
the temptation I am trying to resist. :-)
>The downside:
>- I no longer believe this is the right way to configure
>software or deal with XML configuration :-)
Aaaah? Can you please expand on this?
>BTW, having log4j depend on commons-logging would be a huge benefit for
>the whole community. I know it may be hard for log4j people, but sometimes
>we must make painfull things.
What would be the benefit of log4j depending on commons-logging to the
community? All I tend to see is more complicated bug reports and more
confusion on the user side. (I am afraid we have had this debate already.)
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resisting the temptation
Posted by co...@covalent.net.
Hi Ceki,
I can give you a quick solution - use XmlMapper from tomcat3.3.
It's doing the same thing, works with JDK1.1, no external dependencies
( except IntrospectionUtil - where all the real stuff happens ). It is
quite optimized and tuned and polished.
The downside:
- I no longer believe this is the right way to configure
software or deal with XML configuration :-)
- it is less documented than Digester ( however it is similar enough )
- I don't think we'll make too many changes to it - it works too good to
fix it :-)
BTW, having log4j depend on commons-logging would be a huge benefit for
the whole community. I know it may be hard for log4j people, but sometimes
we must make painfull things.
Costin
On Fri, 10 May 2002, Ceki Gülcü wrote:
>
> Greetings to all,
>
> As most of you are probably aware, log4j version 1.2 final was released
> just a few hours ago. One of the important planned new features of
> log4j 1.3 is the capability to interpret configuration files (in XML)
> with tags that were unknown at compile time. In other words, we would
> like log4j to be able to learn about new tags dynamically. This
> probably similar to ANT's capability of learning new tasks.
>
> The commons-digester library offers the infrastructure to support such
> capability. In short, I think commons-digester has what log4j
> needs. However, commons-digester requires commons-collections,
> commons-beanutils and commons-logging. Here is short list of concerns
> in increasing order of importance:
>
> 1) That's log4j.jar plus 4 jars instead of just log4j.jar.
>
> 2) Commons-xxx depends on JDK 1.2 where as log4j runs with JDK 1.1.
>
> 3) Circular dependencies. Log4j depends on commons-digester, which
> depends on commons-logging which depends on log4j.
>
> Given this seemingly intractable concerns, I have asked Costin
> Manolache, Craig McClanahan and Scott Sanders to borrow the
> commons-digester code. They all graciously granted permission for the
> modification of their code and its inclusion in log4j.
>
> So what's problem you might ask? Well, it seems rather wasteful to
> start a new code base while a perfectly good one exists already. In
> other words, I am trying to resist the urge to start all over again.
>
> Concern number 1), that is the increase in the number of jars, is a fact
> of (modular) life. As for concern 2), log4j can enforce that the extensible
> configuration capability requires JDK 1.2 while the rest remains JDK 1.1
> compatible. Concern 3) is the one I find most challenging. There are 3
> possible approaches:
>
> 1) commons-digester et al. drop the requirement for commons-logging.
> 2) log4j accepts to depend on commons-logging
> 3) some new innovative approach...
>
> Solution 1) is probably not acceptable to the commons community.
> Solution 2 is not acceptable to the log4j community. Solution 3
> requires a fresh approach. Can you please help us find a solution in order to
> resist the temptation?
>
> TIA, Ceki
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>