Re: [logging] JCL in SLF4J flavour - a demo for discussion

[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

[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