On 2/20/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > Standalone applications, applets, embedded systems would use a > lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL stuff, > no dynamic discovery stuff, only one logging adapter. > > Webapps that want to use a specific logging lib would bundle a > lib-specific jar (of course that only works when child-first > classloading is selected or the container doesn't provide JCL). [1] > > Containers would generally bundle commons-logging-dynamic.jar, and would > end up with exactly the same functionality that exists now. They *could* > (as you mention) use a lib-specific implementation if they are happy to > have every webapp use one logging lib but commons-logging-dynamic would > be the usual choice.
That's good. I think the ability to prevent webapps from using the logging they want could be a good feature too. > As a result, this wouldn't reduce any of the existing complexity for > JCL-in-containers (except that we can discard code that tries to handle > embedded systems & java1.1, as those systems can use the lib-specific > ones). However I hope we've nailed many of the outstanding > container-based issues in the 1.1 release anyway, which > LogFactoryDynamic will effectively inherit. This *will* resolve issues > in non-container environments as those can use the simpler jars. > > [1] Hmm..one thing we've discovered is that it's a bad idea to have two > jars in the classpath providing the Log interface. JCL1.1 provides a > "commons-logging-adapters.jar" for webapps to use when the container > provides commons-logging.jar. But the proposed jars I've shown here > include Log so aren't safe to use from a webapp when any other jcl jar > is in a shared path. More thought needed :-( Yes, usually, there are problems with multiple Log definitions. > > - Please continue providing support for using the TCCL (as the TCCL - > > or similar - is used in most JNDI impls, doing otherwise is a bit > > redudant as far as I am concerned, and JNDI access is most likely > > slower). > > I'd be very interested in your opinion about the safety/stability of > TCCL-based solutions. I was looking at Sun's java bugtracker recently > and found an issue raised by JBoss stating that they wanted some > classloader synchronisation code changed as Marc Fleury has been > experimenting with "dependency-based classloaders that aren't tree > structured". From the comments it seems like a few other people are > experimenting with similar approaches. So is it still going to be safe > in the long run to assume every webapp has a distinct TCCL, and that it > is possible to walk up the classloader ancestry links to find all > possible implementations of a particular class? I was pointing out that TCCL was being used to track the logging environment. For classloading itself, it's up to you to figure it out :) > > - If you're changing the API, I think you should consider using > > java.util.logging as the facade API to replace the commons-logging 1.0 > > API. While the API exposed might be a bit sub optimal, this would be > > the most "standard" way from users' perspective. See JULI in Tomcat, > > and www.x4juli.org for java.util.logging "implementations" (providers > > may be more accurate), but both are done using the > > full-logging-implementation way, so maybe not very good examples, as > > you would want to only develop facades. > > I don't quite understand what you mean here. > > Are you suggesting that commons-logging-xxx.jar should include our > implementations of "java.util.logging.*" classes? I don't think that's > allowed/possible... I think providing a LogManager and the appropriate facade Loggers, I don't see why it wouldn't work, but I didn't look that deeply into the feasability. > Or are you suggesting that we write an implementation of > j.u.l.LogManager so that the commons-logging-xxx.jar can be "plugged in" > as a j.u.l implementation? I had made the assumption that JCL would be > supporting java versions earlier than 1.4. I guess I should check, but I > would think that the consensus is that we can't assume 1.4+ for JCL2.x Well, that works too I guess, you could have one of the facades be a facade for c-l. > Or are you suggesting that we model the JCL api on j.u.l so that moving > between the two is a minor search-and-replace? I agree that j.u.l is > eventually going to be the standard logging interface (5-10 years away) > by virtue of it being in the java standard libs. However there is > significant benefit for the JCL project in keeping changes to the > existing API small; the major users of JCL2.x will be existing JCL1.x > users. In addition, much of the j.u.l API is about configuration which > is something that JCL explicitly doesn't do; it wraps the *logging* > parts only. JCL also has to be a "least common denominator" API, so > deliberately leaves out things like a Level class. By the time all those > things are left out, I don't think the remainder would look much like > j.u.l anyway! Personally, if I have to change the logging API, I would rather switch to a standard now (if it's possible). As far as c-l goes, if supporting old JDKs is necessary, this could be an issue ;) -- xxxxxxxxxxxxxxxxxxxxxxxxx Rémy Maucherat Developer & Consultant JBoss Group (Europe) SàRL xxxxxxxxxxxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
