--- James Carman <[EMAIL PROTECTED]> wrote: > I think he meant that there would be a "mock" or > "no-op" implementation > inside the jar. So, you could download this minimal > jar file and include > that on the classpath. No logging would actually > occur, but it would > satisfy the dependencies. I would imagine that some > of the "core" classes > would have to be included also. > > I don't know if this has ever been discussed or not, > but could we not split > JCL up into a bunch of different jars containing the > different > implementations? Each implementation jar (one for > Log4J, Avalon, JDK14, > etc.) would contain a file called something like > "/META-INF/jcl-module.xml" > or whatever. It could actually just be a properties > file, I would imagine. > Anyway, then that file is looked up at runtime to > determine the > implementation the user wishes to use. If they want > to use log4j, they > would include the commons-logging-log4j.jar file on > the classpath. If they > want to use the "no-op" implementation, they'd > include the > commons-logging-noop.jar file on the classpath. > This is similar to what we > do in HiveMind. It might work here. I don't know. > Just a thought. There > would be an issue if the user included two different > implementations on the > classpath. I guess the one that shows up first on > the classpath would get > loaded. > > James > > -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Saturday, December 10, 2005 9:14 PM > To: Jakarta Commons Developers List > Subject: Re: [jcl] mocks > > On Sat, 2005-12-10 at 22:42 +0100, Torsten Curdt > wrote: > > As some projects are not really happy with the JCL > > dependency it would be nice to have a simple and > > small mock jar ...just to justify the dependency. > > > > Any objections to add this to the JCL codebase > > and build system? ...or should that be hosted > > somewhere else? > > What exactly do you mean by "mock jar", and how does > this "justify the > dependency"? > > Cheers, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > >
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 Wade --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
