Hi Boris, Boris Unckel wrote on Tuesday, April 03, 2007 6:50 PM:
> Hello Simon, > > Simon Kitching wrote: >> Would you both mind explaining what benefits you see in a new JCL >> implementation that cannot be obtained via java.util.logging? >> > this is possible already today with x4juli, it does have a JCL native > implementation. > >> I'm no fan of the j.u.l design, but it seems to me less effort to >> use it than to fight it. What have I not understood? [snip] > One last point: The extension of JUL always requires classes on the > system classpath. This is especially > annoying if you have application specific dynamic filters in > a container > because you cannot deploy everything > together, you must change the container config. Yeah. That was one of my traps when I naively implemented a much more useful formatting. IMHO this is the main reason why JUL fails to attract people. >> And what would a new JCL do for anyone that they could not do by just >> using SLF4J via its JCL API? The SLF4J team have already done a lot >> of hard work; what benefit would there be to duplicating that? > The benefit is to have the same way of control as SLF4J. > Maybe the need > for bridging is heavily > reduced. I personally do not like the JCL -> SLF4J -> > CurrentUnderlyingLibrary or the > SLF4J -> JCL -> CurrentUnderlyingLibrary way. It seems better > to me to > have both wrappers > directly sending to the underlying library. > > This code has been presented to be discussed, to get away from > theoretical thoughts without any prove of concept or similiar - > thanks for participating > the discussion. > What is your prefered way of underlying library discovery? Configuration. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
