commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject RE: [jcl] mocks
Date Sun, 11 Dec 2005 06:20:32 GMT
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



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


Mime
View raw message