--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-12-10 at 18:54 -0800, Wade Chandler
> wrote:
>
> > You could always have a wrapper which defaults to
> JCL.
> > Then use a static property system and
> > System.setProperty (for simplicity sake). Need
> both
> > for web-apps sake because it's not good to use
> > System.setProperty in a web-app considering
> multiple
> > web-apps 1 VM and System class, and tell the user
> they
> > can set this value to work around the issue if
> they
> > don't like the default. Define the LoggingFactory
> in
> > an interface, provide wrapper implemenations for
> the
> > common/best known logging packages, and the
> "no-op"
> > version, and for the others they can implement in
> > interface extensions if they are not happy. Then
> have
> > a LogFactoryFactory class which creates the
> LogFactory
> > for the logging based on the simple
> implementation.
> > This might even be a good solution for a broken
> out
> > separate Apache API to allow all the Apache
> products
> > to be that flexible. Then you don't have to worry
> > about the user not being able to use their own
> > implementations of logging. Even the idea of a
> > commons simple static property system could become
> > it's own Apache API to allow all Apache products
> to
> > make themselves configurable in this way. It also
> > allows a defined documented cross properties API
> to be
> > created and used among the different projects.
> Being
> > defined, documented, and commonly used being the
> best
> > factors I think. The recommended use would be to
> not
> > install as a JVM extension. :-D
>
> I think you've described exactly what
> commons-logging currently does.
>
> Regards,
>
> Simon
>
Yep...someone noticed. I don't see why people
complain over it...yet that is... considering the jar
sizes. Technically once a setup/configuration is
setup it's finished. Which the end result is it takes
up just as much time to set a property as it does to
write a line of code.
Anyways....
1) The ant targets should be pretty easy to write to
strip out the different packages and make the
independent jars.
2) All you really have to change then:if some property
file exists on the class path open it up, read it, and
load that class. Else do what you currently do. I
wouldn't even worry about multiple copies. I would
just use LogFactory.class.getResource("/..."); like it
currently does and call it a day on that one...I
wouldn't even change the search..just include the
properties file.
So you're really only looking at a few lines of code,
and some ANT or Maven script changes. To do what has
been proposed. You'll spend most of the time in the
build scripts considering there really isn't much need
as far as configuration goes for JCL itself. I would
just use a simple properties file like it currently
uses. I would simply pre-include it in the jar file
and leave it at that..modifying the build scripts of
course. I mean, if the users don't want the
dependency then they won't have the System property,
services, or commons-logging.properties file setup
anyways.
That's my 2 pints,
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
