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?
JCL apps/libraries are widely spread. A change in the interface or the
public factory methods is
very unlikely. The difference between JCL 1.0.x, 1.1.x and JCL in SLF4J
style is just the way
of packaging (which classes are in the different jars) and the binding
(without autodiscovery,
currently (to be discussed) without classloader support). Another
difference is the check and use for
native implementations.
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.
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?
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
