You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Boris Unckel <bo...@gmx.net> on 2007/03/23 19:56:57 UTC
[logging] JCL in SLF4J flavour - a demo for discussion
Hello,
I have seen the recent discussions on JCL 2.0.0 and a version without
autodiscovery.
Someone stated to stop any further development (with good reasons
behind) but I am
thinking different.
Please have a look at the (working) code:
https://issues.apache.org/jira/browse/LOGGING-112
It has a static binding, some improvements in the logfactories
(recognizes native implementations).
API and implementations are cleanly separated, the 1.1.x diagnostic
function is still used.
What are your thoughts?
Is this a possible direction?
Is it worth to put more time and energy into this?
Regards
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Hi,
Hello there,
I am a little late in this discussion but anyways...
@Simon: JUL is crap. It is NOT an option. Maybe people are using it, but I can
not help them. Eigther use Log4j directly or use JCL.
Why dont we ask the Java community to include the JCL API into the JDK?
Isnt it open-source now? ;)
>
> I just had a quick look at the 2.0.0 api, and there are some features
> that seem to be missing which would be really nice to have. For one of
> them I already created a JIRA entry a time ago, another one I came
> across because I use SLF4J a lot now.
>
> 1) It would be nice to have a generic log method in the Log interface,
> which allows you to log with an arbitrary log level (LOGGING-110).
+1 from me.
>
> 2) It would be nice to have formatting of log messages as SLF4J has with
> the MessageFormat api. In combination with varargs (java5); this makes
> for a really flexible logging mechanism which makes the code much more
> concise and avoids testing for log level and formatting of messages
> yourself while still remaining efficient, e.g., something like this:
>
> log.debug("The disk \"{1}\" contains {0} file(s).", count, disk);
>
> A possible method signature problem could occur here (if there is a var
> args version of the method) because it would conflict with the version
> that also has the throwable as an argument. A solution would be to have
> the throwable first, i.e., log.debug(throwable, messageFormat,
> arguments...). If JCL 2.0.0 needs to be designed to be java 1.4
> compatible, having versions with the Object[]'s instead of varargs would
> still be immensely useful though.
After all I see that 2.0.0 has to be compatible to earlier releases for the API
user. Otherwise the 2.0.0 is dead right away!!!
So the only chance is to keep the Log interface unchanged and add a new
interface Logger (you remember the discussion)?
If you are going to do this, I would be pleased also to come up with my
addChildLogger toppic ;)
https://issues.apache.org/jira/browse/LOGGING-95
Of course there would be other ways to allow the varargs syntax without breaking
compatibility.
The simplest one would be to use other method names ;)
>
> Just some thoughts,
> Sebastiaan van Erk.
Regards
Jörg (still alive)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGuhXvmPuec2Dcv/8RAkfdAJ0T1BOS98MrIt9hbpOmahQN5i/w5gCgkDqR
VgOYADPug2Pb/2eEslYc/cY=
=tWNn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
I just had a quick look at the 2.0.0 api, and there are some features
that seem to be missing which would be really nice to have. For one of
them I already created a JIRA entry a time ago, another one I came
across because I use SLF4J a lot now.
1) It would be nice to have a generic log method in the Log interface,
which allows you to log with an arbitrary log level (LOGGING-110).
2) It would be nice to have formatting of log messages as SLF4J has with
the MessageFormat api. In combination with varargs (java5); this makes
for a really flexible logging mechanism which makes the code much more
concise and avoids testing for log level and formatting of messages
yourself while still remaining efficient, e.g., something like this:
log.debug("The disk \"{1}\" contains {0} file(s).", count, disk);
A possible method signature problem could occur here (if there is a var
args version of the method) because it would conflict with the version
that also has the throwable as an argument. A solution would be to have
the throwable first, i.e., log.debug(throwable, messageFormat,
arguments...). If JCL 2.0.0 needs to be designed to be java 1.4
compatible, having versions with the Object[]'s instead of varargs would
still be immensely useful though.
Just some thoughts,
Sebastiaan van Erk.
Boris Unckel wrote:
> Hello,
>
> I have seen the recent discussions on JCL 2.0.0 and a version without
> autodiscovery.
> Someone stated to stop any further development (with good reasons
> behind) but I am
> thinking different.
>
> Please have a look at the (working) code:
> https://issues.apache.org/jira/browse/LOGGING-112
>
> It has a static binding, some improvements in the logfactories
> (recognizes native implementations).
> API and implementations are cleanly separated, the 1.1.x diagnostic
> function is still used.
>
> What are your thoughts?
> Is this a possible direction?
>
> Is it worth to put more time and energy into this?
>
> Regards
> Boris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote:
> Hello,
>
> I have seen the recent discussions on JCL 2.0.0 and a version without
> autodiscovery.
> Someone stated to stop any further development (with good reasons
> behind) but I am
> thinking different.
>
> Please have a look at the (working) code:
> https://issues.apache.org/jira/browse/LOGGING-112
>
> It has a static binding, some improvements in the logfactories
> (recognizes native implementations).
> API and implementations are cleanly separated, the 1.1.x diagnostic
> function is still used.
>
> What are your thoughts?
> Is this a possible direction?
>
Hi Boris,
I think this patch represents the way I personally would like to see JCL
evolve in the future. If JCL 2.0 were being developed along these lines,
I (personally) would be very inclined to continue using JCL for the next
major version of HttpClient.
> Is it worth to put more time and energy into this?
>
I think it is.
Cheers,
Oleg
> Regards
> Boris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Torsten Curdt <tc...@apache.org>.
Just briefly scanned through ...but I like that direction!
Only suggestion is to rename commons-logging-api to commons-logging-
core ...it has more than just the API definition in it.
cheers
--
Torsten
On 23.03.2007, at 19:56, Boris Unckel wrote:
> Hello,
>
> I have seen the recent discussions on JCL 2.0.0 and a version
> without autodiscovery.
> Someone stated to stop any further development (with good reasons
> behind) but I am
> thinking different.
>
> Please have a look at the (working) code:
> https://issues.apache.org/jira/browse/LOGGING-112
>
> It has a static binding, some improvements in the logfactories
> (recognizes native implementations).
> API and implementations are cleanly separated, the 1.1.x diagnostic
> function is still used.
>
> What are your thoughts?
> Is this a possible direction?
>
> Is it worth to put more time and energy into this?
>
> Regards
> Boris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Boris Unckel <bo...@gmx.net>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2007-04-03 at 22:51 +1200, Simon Kitching wrote:
> On Mon, 2007-03-26 at 15:51 +0200, Oleg Kalnichevski wrote:
> > On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote:
> > > Hello,
> > >
> > > I have seen the recent discussions on JCL 2.0.0 and a version without
> > > autodiscovery.
> > > Someone stated to stop any further development (with good reasons
> > > behind) but I am
> > > thinking different.
> > >
> > > Please have a look at the (working) code:
> > > https://issues.apache.org/jira/browse/LOGGING-112
> > >
> > > It has a static binding, some improvements in the logfactories
> > > (recognizes native implementations).
> > > API and implementations are cleanly separated, the 1.1.x diagnostic
> > > function is still used.
> > >
> > > What are your thoughts?
> > > Is this a possible direction?
> > >
> >
> > Hi Boris,
> >
> > I think this patch represents the way I personally would like to see JCL
> > evolve in the future. If JCL 2.0 were being developed along these lines,
> > I (personally) would be very inclined to continue using JCL for the next
> > major version of HttpClient.
>
> Would you both mind explaining what benefits you see in a new JCL
> implementation that cannot be obtained via java.util.logging?
>
> 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?
>
> 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?
>
> Regards,
>
> Simon
>
Let me take my best shot at trying to explain it.
(1) HttpClient is meant to be a low level transport library and as such
it is supposed to be as non-intrusive toward its upstream dependencies
as possible. To me _personally_ this also means not imposing a
particular choice of a logging toolkit. The reliance on JUL for logging
in HttpClient 4.0 would seem to prevent the use of some popular
toolkits. I am _personally_ not aware of a good JUL to Log4J adapter
(2) I _personally_ am fine with just dumping JCL in favor or SLF4J, but
other HttpComponents committers are currently not.
(3) The only serious gripe about JCL I am aware of is its auto-discovery
mechanism. There _appears_ to be a consensus, please correct me if I am
wrong, that auto-discovery was indeed a mistake.
(4) I _personally_ still have a rather naive belief that Jakarta stands
for something and we should "eat our own dog food" whenever possible. If
JCL 2.0 were to address the auto-discovery issue, that would remove my
only reservation about using JCL in HttpClient 4.0.
That's just my take on the issue for what it is worth.
Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] JCL in SLF4J flavour - a demo for discussion
Posted by Simon Kitching <sk...@apache.org>.
On Mon, 2007-03-26 at 15:51 +0200, Oleg Kalnichevski wrote:
> On Fri, 2007-03-23 at 19:56 +0100, Boris Unckel wrote:
> > Hello,
> >
> > I have seen the recent discussions on JCL 2.0.0 and a version without
> > autodiscovery.
> > Someone stated to stop any further development (with good reasons
> > behind) but I am
> > thinking different.
> >
> > Please have a look at the (working) code:
> > https://issues.apache.org/jira/browse/LOGGING-112
> >
> > It has a static binding, some improvements in the logfactories
> > (recognizes native implementations).
> > API and implementations are cleanly separated, the 1.1.x diagnostic
> > function is still used.
> >
> > What are your thoughts?
> > Is this a possible direction?
> >
>
> Hi Boris,
>
> I think this patch represents the way I personally would like to see JCL
> evolve in the future. If JCL 2.0 were being developed along these lines,
> I (personally) would be very inclined to continue using JCL for the next
> major version of HttpClient.
Would you both mind explaining what benefits you see in a new JCL
implementation that cannot be obtained via java.util.logging?
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?
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?
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org