(and he seems to disagree ;) )
Let the fight continue! :)
On 12/12/2007 03:27 PM, David M. Lloyd wrote:
Well... honestly I don't know which bugs he's referring to.
But
providing a custom LogManager basically lets you provide a complete
replacement implementation for the Logger class if you want, so it
seems likely.
- DML
On Wed, 12 Dec 2007 15:19:09 +0100
Sacha Labourey <sacha.labourey(a)jboss.com> wrote:
> are you sure it is possible to provide an implementation of JUL that
> work around the bugs mentioned by Adrian?
>
> On 12/12/2007 03:04 PM, David M. Lloyd wrote:
>> On Wed, 12 Dec 2007 12:31:52 +0100
>> Adrian Brock <abrock(a)redhat.com> wrote:
>>
>>> Why do we keep having this thread over and over again
>>> with ever new developer?
>> Because you're wrong? ;-) J/K, but read on.
>>
>>> 1) Use the jboss logger
>>>
>>> JBoss has a very simple wrapper, as Jason and Scott explained.
>> Great. Now my project requires the jboss wrapper. But my project's
>> two dependencies require slf4j and log4j, making three different JARs
>> in total, just for logging. Problem solved!
>>
>>> The logic is
>>> if (system property set)
>>> use implementation of system property
>>> else if (log4j in classpath)
>>> use log4j
>>> else
>>> don't log
>>>
>>> Advantages:
>>> * You can choose log4j, jdk logging or implement a wrapper
>>> to your own logging framework
>> This choice is purely illusion. It seems like I have such a choice,
>> but the reality is that I'm locked in to requiring a dependency -
>> the jboss-common-logging jar. How is this better than using slf4j?
>>
>> On the other hand, if I use JUL then the problem is reduced - now the
>> user need only include slf4j and log4j JARs. I think I've convinced
>> Clebert to switch to JUL for jboss-serialization (though I bet he'll
>> want to see what the outcome of this discussion is first), so that would
>> get rid of the log4j - then it's just down to slf4j in MINA, which I'm
>> currently lobbying on their mailing list. If I succeed in my efforts,
>> the user will have *no* external logging JARs needed for MINA, JBoss
>> Serialization, *or* Remoting.
>>
>>> * You can choose not to log at all, e.g. in a client
>>> where you don't control the logging configuration at all
>>> * It is very small
>>>
>>> $ du -h jboss-common-logging-spi-2.0.5-SNAPSHOT.jar
>>> 16K jboss-common-logging-spi-2.0.5-SNAPSHOT.jar
>> This is good for things running within the container, but in the
>> standalone case it's no different (to the user) than if I required
>> commons-logging or slf4j myself. Except that nobody else on the planet
>> (well, outside of JBoss) would ever depend on jboss-common-logging.
>>
>> The fact is, zero JARs is better than one, no matter how small it is.
>>
>>> 2) There are many thirdparty components using different logging
>>> frameworks. Even things like Hibernate and JGroups use clogging.
>>>
>>> Unless we are going to fork them to fix the logging
>>> we're always going to have to deal with many logging frameworks.
>>> (Most of them are from Apache - let a thousand WEEDS bloom :-)
>> Gotta start somewhere. If I can convince MINA, perhaps other Apache
>> projects will also see reason. :-)
>>
>> Just because few people hold this viewpoint today doesn't mean that
>> more won't tomorrow.
>>
>>> 3) JDK logging is broken/useless
>>>
>>> There are many bugs in the JDK logging that lead to deadlocks,
>>> memory leaks or just broken behaviour, we have workarounds
>>> for some of them (as usual a spec written for JavaSE
>>> doesn't anticipate the needs of JavaEE :-)
>>> And as has been already said, there are no useful appenders.
>>> Maybe with JDK7 we can fix/mitigate these problems?
>> Waiting for JDK7 to fix anything is... well, let's not do that. I'm
>> with Trustin on this - let's do a
JBoss.org project for adding support
>> to JDK logging to make it useful. A LogManager to delegate to popular
>> logging frameworks would be a great start - as would a collection of
>> useful appenders. This basically makes JDK logging into a built-in
>> commons-logging of sorts - it becomes the user's choice what logging
>> backend to use.
>>
>> It would be my hope that the log4j/logback/etc of the world would
>> integrate code to provide a LogManager of their own that would
>> intercept JDK logging and handle it properly. I think if we initiate
>> this effort, they will follow.
>>
>> In any case, by using JDK logging in these middle pieces, the user
>> can just include JARs for the logging backend/API that they like. This
>> is the real crux of the whole issue.
>>
>>> I'm sure this thread will appear again in 6 months when
>>> the next new developer joins the project.
>> When they run into the same problem and get frustrated by the lack of a
>> good solution? Sure.
>>
>>> Logging always seems to be one of those flamebait topics,
>>> I don't see why, it really isn't that interesting. :-)
>> If "interesting" were the only criteria...
>>
>> - DML
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development