On Sun, 2005-12-11 at 21:48 +0100, Torsten Curdt wrote: > > dependencies should be declared against the API and not the > > implementation. > > Sure ...but that API jar also includes implementations. > Can anyone explain why?
history :( the jar serves two functions which should have been kept separate: 1 to act as the API which other projects should compile against 2 as a jar which contains a subset of the implementation classes carefully chosen to allow the classloader magic to work correctly in certain classloader configurations IMO these are mutually antagonistic aims > > IMO the biggest mistake made with JCL was that the API > > jar is not runnable. creating a new NoOp jar and declaring a > > dependency > > upon it is positively wrong since that will mess up dependency > > management graphs. > > Runnable? perhaps non-explosive or fail-safe would have been a more accurate description of what i meant. you should be able to include the API jar alone in your classpath and have some reasonable behaviour when you call getLog (for example, discarding all logs) rather than exploding in a fit of runtime exceptions. > Messing up the dep graph? Can you elaborate > ...don't get it. X depends on JCL_API, but Y depends on NoOpLog and Y. transitive resolution would lead to assuming that Y depends on NoOpLog, JCL_API and X. maven 2, gump and other systems use this kind of thing. not sure how good the provides-implementation-of logic is yet... IMHO it's much cleaner if the JCL API dependency could be used safely by itself. in other words, if the basic API jar had some reasonable behaviour (for example, discarding all log messages) when used alone. then both X and Y could safely depend on the API jar. > > the api jar is now used not only as the basic JCL dependency but also > > for complex classloader configurations. it's actually a special jar > > arranged to allow JCL to be deployed in various classloader setups. > > IMO > > this was the second fatal mistake in the development of JCL > > > > what's really needed is not a NoOp jar but a jar that's runs > > containing > > definitions of the core API (Log and LogFactory) without anything > > else. > > (i've taken a look before at creating such a beast and found it > > difficult.) > > Yepp! ...but why is that difficult? the tricks used to satisfy the java 2 and servlet specifications gave rise to some nasty runtime couplings. JCL used to assume that (unless the user specified an alternative implementation) if LogFactoryImpl cannot be loaded then an exception must be thrown since something was seriously wrong. i think that there's a chance that this is no longer with case with the latest code but i'd need to sit down and analysis the code... the risk must also be considered of the API jar being loaded by a high level container classloader and preventing the careful classloader tricks working correctly. > > but that actually satisfy your downstream users? > > > > FWIW distributing a combined library with a NoOp implementation may > > well > > cause problems with any application using JCL. the possible known > > classloading configurations would need to be analysed carefully or the > > presence of NoOp in the classloader hierarchy may well cause problems. > > IMO it would be more robust to use byte code enhancement to swallow > > all > > logging calls (if that's what your downstream customers really want). > > Removing logging via bytecode modifications would be another > option ...but I am not sure how feasible it is. It's definitely > more complicated to remove than to add things at that level. IIRC Chris Nokleberg created something that did just this > > this is ceki's preferred solution. > > I think agree with him here. > > > i prefer dynamic binding > > May I ask why? ...or point to the thread in the archive. > I am sure you explained that before ;) > > > (run an > > enhancer against the library in question which does the same job). > > What do you mean by that? sorry: should have said that i prefer byte-code enhancement of the library (using the logging) to compile time static binding. JCL 1.x uses dynamic binding. the idea is that you static bind a particular library to a particular logging implementation by running an enhancer. so, if you want a library to log to log4j, you run the log4j enhancer on the jar. a main advantage of static binding is that it's easy to explain and to configure. but there are some things which compile time static binding can't do that dynamic binding can. in particular, you can set up configurations with jars loaded by top level classloaders and still allow applications to have separate configurations. this seems like it was really important back in the servlet days when one target was commercial hosters of web applications... you can do tricks with an enhancers that can't be done at compile time. but different approaches to binding could be (in some ways) complementary. > > unfortunately, as far as i can tell, a proper implementation is not > > possible without breaking backwards compatibility. > > > > thanks to hard work by simon and brian, the current JCL is known to be > > much better than any before. we have a matrix of possible classloader > > configurations and those which the specifications allow to be solvable > > appear to work ok now. > > Yes, that's great ...but I still have an urge for a JCL2 so does everyone but 1.1 is a prerequisite: we need to ship something that fixes everything that can be fixed. isolating the problematic use cases is important since it means that we can be sure that what comes next addresses them... - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
