noon
Developing Remoting 3 I discovered that, thanks to depending on MINA
and JBoss Serialization, I now have an indirect dependency on both
log4j and slf4j. This sucks. I'm tired of dealing with issues with
logging when this problem should have been solved years ago.
I've asked Clebert to change JBoss Serialization to use JDK logging.
His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
(except for the wedge that Stan Silvert wrote for JSF).
My feelings are as follows:
* The JBossAS logging system must be changed such that BY DEFAULT log
messages are all handled properly (in terms of category and level),
regardless of the logging framework used (java.util.logging or log4j).
No, relying on the System.out/System.err capture mechanism is NOT
sufficient for this task. This means that, as far as I can tell, we
should always be installing a JUL LogManger on appserver startup.
Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
do this out of the box.
* ALL framework devlopers should switch to java.util.logging. This is
the ONLY way you can have logging without introducing a JAR
dependency. Yeah the API kind of sucks, but it's easily worked around
(here's one way: http://tinyurl.com/3848rr - notice the lack of
external JAR dependencies). It's far better for the framework
developer to embrace suckage, so that the end-user doesn't have to.
* The end application developer should be able to use whatever
logging API they like the best without surprises.
A while back Scott indicated that there would be the option of a JDK
logger in AS 5, and maybe it would even be the default one. The
discussion thread is at:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
though unfortunately, the whole theme of the discussion is "which
logging framework to use, log4j or jdk" and the issue was confused by
the faulty assumption that by using one, we would no longer be able to
support the other. So I'm actually sort of confused as to the outcome
of that.
In any case, Remoting 3 will use JDK logging, at least until someone
stops me. And I will continue my efforts to get JBSER and MINA changed
over to JDK logging as well.
- DML
12:16 p.m.
I'd love to switch over to the JDK logging (I could drop the
commons-logging and log4j JARs), but I'm told it seriously sucks, not in
terms of the API (which can be wrapped), but in terms of configuration
from a users point of view. And I'm not talking about the appserver
which comes with logging enabled, I'm talking about libs like JGroups
which make the dev who integrates JGroups have the pain.
BTW, JGroups won't use MINA until it drops the dependency on slf4j.
David M. Lloyd wrote:
Developing Remoting 3 I discovered that, thanks to depending on MINA
and JBoss Serialization, I now have an indirect dependency on both
log4j and slf4j. This sucks. I'm tired of dealing with issues with
logging when this problem should have been solved years ago.
I've asked Clebert to change JBoss Serialization to use JDK logging.
His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
(except for the wedge that Stan Silvert wrote for JSF).
My feelings are as follows:
* The JBossAS logging system must be changed such that BY DEFAULT log
messages are all handled properly (in terms of category and level),
regardless of the logging framework used (java.util.logging or log4j).
No, relying on the System.out/System.err capture mechanism is NOT
sufficient for this task. This means that, as far as I can tell, we
should always be installing a JUL LogManger on appserver startup.
Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
do this out of the box.
* ALL framework devlopers should switch to java.util.logging. This is
the ONLY way you can have logging without introducing a JAR
dependency. Yeah the API kind of sucks, but it's easily worked around
(here's one way: http://tinyurl.com/3848rr - notice the lack of
external JAR dependencies). It's far better for the framework
developer to embrace suckage, so that the end-user doesn't have to.
* The end application developer should be able to use whatever
logging API they like the best without surprises.
A while back Scott indicated that there would be the option of a JDK
logger in AS 5, and maybe it would even be the default one. The
discussion thread is at:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
though unfortunately, the whole theme of the discussion is "which
logging framework to use, log4j or jdk" and the issue was confused by
the faulty assumption that by using one, we would no longer be able to
support the other. So I'm actually sort of confused as to the outcome
of that.
In any case, Remoting 3 will use JDK logging, at least until someone
stops me. And I will continue my efforts to get JBSER and MINA changed
over to JDK logging as well.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
12:31 p.m.
This is my point - on the one hand you reject the only solution, and on
the other, you refuse to use an otherwise good library because of the
problem. :-)
But my point is exactly this. JDK logging is two things. First, it's
a logging API - like commons-logging, but *built in*! Second, it's a
(pretty crappy) appender framework.
OK, sure, the handlers aren't that great. But guess what? The user
already has stuff using JDK logging just by virtue of using the JDK!
And just about every container supports JDK logging (well, except for
ours anyway).
Trust me, the user would rather deal with (just) JDK logging than
having 4 different logging JARs in their classpath.
Has anyone ever explored the possibility of getting the log4j people to
supply a JDK LogManager that maps JDK logging to log4j? That would
solve the non-container case. I may take a day this week to just write
one, or rather adapt the one I've already written.
- DML
On Tue, 11 Dec 2007 18:16:39 +0100
Bela Ban <bela(a)jboss.com> wrote:
I'd love to switch over to the JDK logging (I could drop the
commons-logging and log4j JARs), but I'm told it seriously sucks, not in
terms of the API (which can be wrapped), but in terms of configuration
from a users point of view. And I'm not talking about the appserver
which comes with logging enabled, I'm talking about libs like JGroups
which make the dev who integrates JGroups have the pain.
BTW, JGroups won't use MINA until it drops the dependency on slf4j.
David M. Lloyd wrote:
> Developing Remoting 3 I discovered that, thanks to depending on MINA
> and JBoss Serialization, I now have an indirect dependency on both
> log4j and slf4j. This sucks. I'm tired of dealing with issues with
> logging when this problem should have been solved years ago.
>
> I've asked Clebert to change JBoss Serialization to use JDK logging.
> His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
> (except for the wedge that Stan Silvert wrote for JSF).
>
> My feelings are as follows:
>
> * The JBossAS logging system must be changed such that BY DEFAULT log
> messages are all handled properly (in terms of category and level),
> regardless of the logging framework used (java.util.logging or log4j).
> No, relying on the System.out/System.err capture mechanism is NOT
> sufficient for this task. This means that, as far as I can tell, we
> should always be installing a JUL LogManger on appserver startup.
> Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
> do this out of the box.
>
> * ALL framework devlopers should switch to java.util.logging. This is
> the ONLY way you can have logging without introducing a JAR
> dependency. Yeah the API kind of sucks, but it's easily worked around
> (here's one way: http://tinyurl.com/3848rr - notice the lack of
> external JAR dependencies). It's far better for the framework
> developer to embrace suckage, so that the end-user doesn't have to.
>
> * The end application developer should be able to use whatever
> logging API they like the best without surprises.
>
> A while back Scott indicated that there would be the option of a JDK
> logger in AS 5, and maybe it would even be the default one. The
> discussion thread is at:
>
> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
>
> though unfortunately, the whole theme of the discussion is "which
> logging framework to use, log4j or jdk" and the issue was confused by
> the faulty assumption that by using one, we would no longer be able to
> support the other. So I'm actually sort of confused as to the outcome
> of that.
>
> In any case, Remoting 3 will use JDK logging, at least until someone
> stops me. And I will continue my efforts to get JBSER and MINA changed
> over to JDK logging as well.
>
12:58 p.m.
I think what we really need here is to write another "meta" logging
framework for our projects to use, and that can just delegate to slf4j,
log4j, java.util logging etc ;)
Seriously though, I echo many of David concerns.
We are in a similar position as David (and Bela) with MINA - I don't
really want to pull in a slf4j dependency. Although I understand Trustin
has some difficulty in removing this due to the way Apache democracies
work :(
David M. Lloyd wrote:
This is my point - on the one hand you reject the only solution, and
on
the other, you refuse to use an otherwise good library because of the
problem. :-)
But my point is exactly this. JDK logging is two things. First, it's
a logging API - like commons-logging, but *built in*! Second, it's a
(pretty crappy) appender framework.
OK, sure, the handlers aren't that great. But guess what? The user
already has stuff using JDK logging just by virtue of using the JDK!
And just about every container supports JDK logging (well, except for
ours anyway).
Trust me, the user would rather deal with (just) JDK logging than
having 4 different logging JARs in their classpath.
Has anyone ever explored the possibility of getting the log4j people to
supply a JDK LogManager that maps JDK logging to log4j? That would
solve the non-container case. I may take a day this week to just write
one, or rather adapt the one I've already written.
- DML
On Tue, 11 Dec 2007 18:16:39 +0100
Bela Ban <bela(a)jboss.com> wrote:
> I'd love to switch over to the JDK logging (I could drop the
> commons-logging and log4j JARs), but I'm told it seriously sucks, not in
> terms of the API (which can be wrapped), but in terms of configuration
> from a users point of view. And I'm not talking about the appserver
> which comes with logging enabled, I'm talking about libs like JGroups
> which make the dev who integrates JGroups have the pain.
>
> BTW, JGroups won't use MINA until it drops the dependency on slf4j.
>
> David M. Lloyd wrote:
>
>> Developing Remoting 3 I discovered that, thanks to depending on MINA
>> and JBoss Serialization, I now have an indirect dependency on both
>> log4j and slf4j. This sucks. I'm tired of dealing with issues with
>> logging when this problem should have been solved years ago.
>>
>> I've asked Clebert to change JBoss Serialization to use JDK logging.
>> His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
>> (except for the wedge that Stan Silvert wrote for JSF).
>>
>> My feelings are as follows:
>>
>> * The JBossAS logging system must be changed such that BY DEFAULT log
>> messages are all handled properly (in terms of category and level),
>> regardless of the logging framework used (java.util.logging or log4j).
>> No, relying on the System.out/System.err capture mechanism is NOT
>> sufficient for this task. This means that, as far as I can tell, we
>> should always be installing a JUL LogManger on appserver startup.
>> Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
>> do this out of the box.
>>
>> * ALL framework devlopers should switch to java.util.logging. This is
>> the ONLY way you can have logging without introducing a JAR
>> dependency. Yeah the API kind of sucks, but it's easily worked around
>> (here's one way: http://tinyurl.com/3848rr - notice the lack of
>> external JAR dependencies). It's far better for the framework
>> developer to embrace suckage, so that the end-user doesn't have to.
>>
>> * The end application developer should be able to use whatever
>> logging API they like the best without surprises.
>>
>> A while back Scott indicated that there would be the option of a JDK
>> logger in AS 5, and maybe it would even be the default one. The
>> discussion thread is at:
>>
>> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
>>
>> though unfortunately, the whole theme of the discussion is "which
>> logging framework to use, log4j or jdk" and the issue was confused by
>> the faulty assumption that by using one, we would no longer be able to
>> support the other. So I'm actually sort of confused as to the outcome
>> of that.
>>
>> In any case, Remoting 3 will use JDK logging, at least until someone
>> stops me. And I will continue my efforts to get JBSER and MINA changed
>> over to JDK logging as well.
>>
>>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:06 p.m.
Tim Fox wrote:
I think what we really need here is to write another "meta"
logging
framework for our projects to use, and that can just delegate to slf4j,
log4j, java.util logging etc ;)
We do, it's jboss-commons-logging. :)
Seriously though, I echo many of David concerns.
We are in a similar position as David (and Bela) with MINA - I don't
really want to pull in a slf4j dependency. Although I understand Trustin
has some difficulty in removing this due to the way Apache democracies
work :(
David M. Lloyd wrote:
> This is my point - on the one hand you reject the only solution, and on
> the other, you refuse to use an otherwise good library because of the
> problem. :-)
>
> But my point is exactly this. JDK logging is two things. First, it's
> a logging API - like commons-logging, but *built in*! Second, it's a
> (pretty crappy) appender framework.
>
> OK, sure, the handlers aren't that great. But guess what? The user
> already has stuff using JDK logging just by virtue of using the JDK!
> And just about every container supports JDK logging (well, except for
> ours anyway).
>
> Trust me, the user would rather deal with (just) JDK logging than
> having 4 different logging JARs in their classpath.
>
> Has anyone ever explored the possibility of getting the log4j people to
> supply a JDK LogManager that maps JDK logging to log4j? That would
> solve the non-container case. I may take a day this week to just write
> one, or rather adapt the one I've already written.
>
> - DML
>
> On Tue, 11 Dec 2007 18:16:39 +0100
> Bela Ban <bela(a)jboss.com> wrote:
>
>
>> I'd love to switch over to the JDK logging (I could drop the
>> commons-logging and log4j JARs), but I'm told it seriously sucks, not
>> in terms of the API (which can be wrapped), but in terms of
>> configuration from a users point of view. And I'm not talking about
>> the appserver which comes with logging enabled, I'm talking about
>> libs like JGroups which make the dev who integrates JGroups have the
>> pain.
>>
>> BTW, JGroups won't use MINA until it drops the dependency on slf4j.
>>
>> David M. Lloyd wrote:
>>
>>> Developing Remoting 3 I discovered that, thanks to depending on MINA
>>> and JBoss Serialization, I now have an indirect dependency on both
>>> log4j and slf4j. This sucks. I'm tired of dealing with issues with
>>> logging when this problem should have been solved years ago.
>>>
>>> I've asked Clebert to change JBoss Serialization to use JDK logging.
>>> His (valid) concern is that JBAS 4.2.x doesn't support JDK logging
>>> (except for the wedge that Stan Silvert wrote for JSF).
>>>
>>> My feelings are as follows:
>>>
>>> * The JBossAS logging system must be changed such that BY DEFAULT log
>>> messages are all handled properly (in terms of category and level),
>>> regardless of the logging framework used (java.util.logging or log4j).
>>> No, relying on the System.out/System.err capture mechanism is NOT
>>> sufficient for this task. This means that, as far as I can tell, we
>>> should always be installing a JUL LogManger on appserver startup.
>>> Frankly it really baffles and disappoints me that 4.0.x and 4.2.x
>>> didn't
>>> do this out of the box.
>>>
>>> * ALL framework devlopers should switch to java.util.logging. This is
>>> the ONLY way you can have logging without introducing a JAR
>>> dependency. Yeah the API kind of sucks, but it's easily worked around
>>> (here's one way: http://tinyurl.com/3848rr - notice the lack of
>>> external JAR dependencies). It's far better for the framework
>>> developer to embrace suckage, so that the end-user doesn't have to.
>>>
>>> * The end application developer should be able to use whatever
>>> logging API they like the best without surprises.
>>>
>>> A while back Scott indicated that there would be the option of a JDK
>>> logger in AS 5, and maybe it would even be the default one. The
>>> discussion thread is at:
>>>
>>> http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3904365
>>>
>>> though unfortunately, the whole theme of the discussion is "which
>>> logging framework to use, log4j or jdk" and the issue was confused by
>>> the faulty assumption that by using one, we would no longer be able to
>>> support the other. So I'm actually sort of confused as to the outcome
>>> of that.
>>>
>>> In any case, Remoting 3 will use JDK logging, at least until someone
>>> stops me. And I will continue my efforts to get JBSER and MINA changed
>>> over to JDK logging as well.
>>>
>>>
> _______________________________________________
> 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
--
Jason T. Greene
JBoss, a division of Red Hat
2:32 p.m.
On Tue, 11 Dec 2007 13:06:43 -0500 "Jason T. Greene"
<jason.greene(a)redhat.com> wrote:
Tim Fox wrote:
> I think what we really need here is to write another "meta" logging
> framework for our projects to use, and that can just delegate to slf4j,
> log4j, java.util logging etc ;)
We do, it's jboss-commons-logging. :)
Tim was being ironic I think. Let me answer this in a different way -
jboss commons logging solves the problem within the container just fine.
The container can now (presumably [I haven't tried it yet!]) allow the
user to configure it to use the JDK appender system, or log4j. And
within the container, you've got a much nicer API than either log4j or
JDK logging provides.
But what I'm really referring two are other libraries that require
logging, but may or may not run within a container (ours or others). In
this case, using *any* framework (even meta frameworks like
jboss-commons-logging, slf4j, and apache commons-logging) just causes
more problems for the user, who then needs JARs for every framework and
meta-framework around.
The key advantage to JDK logging is that it's in the JDK. This is
actually it's only advantage IMO - but it is the critical advantage
that makes the difference. If you want logging in your library, but
you don't want to require a JAR for it, you really have no other option.
Tim Fox wrote:
Seriously though, I echo many of David concerns.
We are in a similar position as David (and Bela) with MINA - I don't
really want to pull in a slf4j dependency. Although I understand Trustin
has some difficulty in removing this due to the way Apache democracies
work :(
Well, I've sent a heartfelt appeal to the MINA list, so we'll see what
happens.
- DML
1:03 p.m.
David M. Lloyd wrote:
This is my point - on the one hand you reject the only solution, and
on
the other, you refuse to use an otherwise good library because of the
problem. :-)
But my point is exactly this. JDK logging is two things. First, it's
a logging API - like commons-logging, but *built in*! Second, it's a
(pretty crappy) appender framework.
OK, sure, the handlers aren't that great. But guess what? The user
already has stuff using JDK logging just by virtue of using the JDK!
And just about every container supports JDK logging (well, except for
ours anyway).
Trust me, the user would rather deal with (just) JDK logging than
having 4 different logging JARs in their classpath.
Has anyone ever explored the possibility of getting the log4j people to
supply a JDK LogManager that maps JDK logging to log4j? That would
solve the non-container case. I may take a day this week to just write
one, or rather adapt the one I've already written.
The jboss-common-logging project has a JDK appender with essentially the
same feature set as log4j. I myself added support for MDC and NDC awhile
back. So any jboss project which uses jboss-common-logging, supports
both JDK and log4j logging.
--
Jason T. Greene
JBoss, a division of Red Hat
1:30 p.m.
On Tue, 11 Dec 2007 13:03:41 -0500
"Jason T. Greene" <jason.greene(a)redhat.com> wrote:
The jboss-common-logging project has a JDK appender with essentially
the
same feature set as log4j. I myself added support for MDC and NDC awhile
back. So any jboss project which uses jboss-common-logging, supports
both JDK and log4j logging.
But you've missed the point Jason - if for example, I use jboss common
logging, now my project would require *three* JARs just for logging
(MINA uses slf4j,
My point is that *frameworks* - all the JARs that do stuff between the
end-user code and the container - should not rely on *any* meta-logging
framework. Yeah it sucks for framework developers, but if I were an
end-user that wants to use, say, 7 or 8 frameworks that do various
things, I wouldn't want to have to import 3 or more different logging
meta-frameworks as well - and risk projects having compatibility issues
because project A wanted one version of a logging framework and project
B wanted a different version.
The *container* definitely should provide support for applications
and libraries that use either JDK logging or log4j.
The *end-user* should be able to use whatever API that they like.
Probably they won't directly use the JDK logging API, because it's
pretty ugly. But whether they log a message with JDK logging or log4j,
their message should end up in the log. The important thing is that
they get the final choice of API.
However, all of us who develop all the crap in between need to think:
what dependencies are we imposing on the user? And honestly are we
doing it for their convenience, or our own? As a framework developer,
I'm willing to deal with the JDK logging API so that the end user
doesn't have to deal with more JARs.
- DML
1:38 p.m.
David M. Lloyd wrote:
On Tue, 11 Dec 2007 13:03:41 -0500
"Jason T. Greene" <jason.greene(a)redhat.com> wrote:
> The jboss-common-logging project has a JDK appender with essentially the
> same feature set as log4j. I myself added support for MDC and NDC awhile
> back. So any jboss project which uses jboss-common-logging, supports
> both JDK and log4j logging.
But you've missed the point Jason - if for example, I use jboss common
logging, now my project would require *three* JARs just for logging
(MINA uses slf4j,
You don't need a dependency on it. You can just use the JDK api if you
choose. My point was that it provides an appender.
As to API, anything that uses the log4j API can be easily rewritten to
use the jboss logging api instead, in which case the number of
dependencies remains the same.
--
Jason T. Greene
JBoss, a division of Red Hat
1:42 p.m.
On Tue, 11 Dec 2007 13:38:46 -0500
"Jason T. Greene" <jason.greene(a)redhat.com> wrote:
As to API, anything that uses the log4j API can be easily rewritten
to
use the jboss logging api instead, in which case the number of
dependencies remains the same.
I will definitely agree that relying on jboss logging is no worse than
relying on log4j. :-)
- DML
4:16 p.m.
So now we replace commons-logging.jar with commons-logging-jboss.jar ?
Where does removing a JAR come into play ? :-)
Jason T. Greene wrote:
David M. Lloyd wrote:
> This is my point - on the one hand you reject the only solution, and on
> the other, you refuse to use an otherwise good library because of the
> problem. :-)
>
> But my point is exactly this. JDK logging is two things. First, it's
> a logging API - like commons-logging, but *built in*! Second, it's a
> (pretty crappy) appender framework.
>
> OK, sure, the handlers aren't that great. But guess what? The user
> already has stuff using JDK logging just by virtue of using the JDK!
> And just about every container supports JDK logging (well, except for
> ours anyway).
>
> Trust me, the user would rather deal with (just) JDK logging than
> having 4 different logging JARs in their classpath.
>
> Has anyone ever explored the possibility of getting the log4j people to
> supply a JDK LogManager that maps JDK logging to log4j? That would
> solve the non-container case. I may take a day this week to just write
> one, or rather adapt the one I've already written.
>
The jboss-common-logging project has a JDK appender with essentially
the same feature set as log4j. I myself added support for MDC and NDC
awhile back. So any jboss project which uses jboss-common-logging,
supports both JDK and log4j logging.
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
4:29 p.m.
Good question :) If you want to get rid of a JAR, use the JDK logging
API (writing your own wrapper) for your projects (no dependencies).
Where jboss-common-logging gets interesting is that it provides a log4j
appender framework for JDK logging on JBoss. This, IMO should be the
default, but it's a major change for the AS.
Bela Ban wrote:
So now we replace commons-logging.jar with commons-logging-jboss.jar
?
Where does removing a JAR come into play ? :-)
Jason T. Greene wrote:
> David M. Lloyd wrote:
>> This is my point - on the one hand you reject the only solution, and on
>> the other, you refuse to use an otherwise good library because of the
>> problem. :-)
>>
>> But my point is exactly this. JDK logging is two things. First, it's
>> a logging API - like commons-logging, but *built in*! Second, it's a
>> (pretty crappy) appender framework.
>>
>> OK, sure, the handlers aren't that great. But guess what? The user
>> already has stuff using JDK logging just by virtue of using the JDK!
>> And just about every container supports JDK logging (well, except for
>> ours anyway).
>>
>> Trust me, the user would rather deal with (just) JDK logging than
>> having 4 different logging JARs in their classpath.
>>
>> Has anyone ever explored the possibility of getting the log4j people to
>> supply a JDK LogManager that maps JDK logging to log4j? That would
>> solve the non-container case. I may take a day this week to just write
>> one, or rather adapt the one I've already written.
>>
>
> The jboss-common-logging project has a JDK appender with essentially
> the same feature set as log4j. I myself added support for MDC and NDC
> awhile back. So any jboss project which uses jboss-common-logging,
> supports both JDK and log4j logging.
>
--
Jason T. Greene
JBoss, a division of Red Hat
10:51 p.m.
It should not be that big a change. There is a command line option to
enable this as the default jboss logger implementation. I have not
tested it in quite a while so I don't know if t still works.
On Dec 11, 2007, at 1:29 PM, Jason T. Greene wrote:
Good question :) If you want to get rid of a JAR, use the JDK
logging API (writing your own wrapper) for your projects (no
dependencies). Where jboss-common-logging gets interesting is that
it provides a log4j appender framework for JDK logging on JBoss.
This, IMO should be the default, but it's a major change for the AS.
11:14 p.m.
That is great... BUT... the two options should be: Use log4j with JUL
emulation, or use JUL with log4j emulation. I'm not talking about what
JBossAS is using internally, but what it makes available to the user.
On Tue, 11 Dec 2007 19:51:41 -0800
Scott Stark <sstark(a)redhat.com> wrote:
It should not be that big a change. There is a command line option to
enable this as the default jboss logger implementation. I have not
tested it in quite a while so I don't know if t still works.
On Dec 11, 2007, at 1:29 PM, Jason T. Greene wrote:
> Good question :) If you want to get rid of a JAR, use the JDK
> logging API (writing your own wrapper) for your projects (no
> dependencies). Where jboss-common-logging gets interesting is that
> it provides a log4j appender framework for JDK logging on JBoss.
> This, IMO should be the default, but it's a major change for the AS.
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:45 a.m.
This was using JUL with log4j like loggers/xml configuration. JUL would
be what is available to users, and they would have the jboss intalled
log4j type of loggers. Need to pull together what I'm talking about and
update this page as its not describing the --log=jdk option I added;
http://wiki.jboss.org/wiki/Wiki.jsp?page=Logging
succubus:bin starksm$ ./run.sh -help
...
-l, --log=<log4j|jdk> Specify the logger plugin type
David M. Lloyd wrote:
That is great... BUT... the two options should be: Use log4j with
JUL
emulation, or use JUL with log4j emulation. I'm not talking about what
JBossAS is using internally, but what it makes available to the user.
On Tue, 11 Dec 2007 19:51:41 -0800
Scott Stark <sstark(a)redhat.com> wrote:
> It should not be that big a change. There is a command line option to
> enable this as the default jboss logger implementation. I have not
> tested it in quite a while so I don't know if t still works.
>
>
>
1:01 a.m.
What's the motivation behind this? Just dropping log4j? It seems to
me that we'd want to provide some way for the tons of crap still using
log4j to still log to the log file properly.
- DML
On Tue, 11 Dec 2007 21:45:10 -0800
Scott Stark <sstark(a)redhat.com> wrote:
This was using JUL with log4j like loggers/xml configuration. JUL
would
be what is available to users, and they would have the jboss intalled
log4j type of loggers. Need to pull together what I'm talking about and
update this page as its not describing the --log=jdk option I added;
http://wiki.jboss.org/wiki/Wiki.jsp?page=Logging
succubus:bin starksm$ ./run.sh -help
...
-l, --log=<log4j|jdk> Specify the logger plugin type
David M. Lloyd wrote:
> That is great... BUT... the two options should be: Use log4j with JUL
> emulation, or use JUL with log4j emulation. I'm not talking about what
> JBossAS is using internally, but what it makes available to the user.
>
> On Tue, 11 Dec 2007 19:51:41 -0800
> Scott Stark <sstark(a)redhat.com> wrote:
>
>
>> It should not be that big a change. There is a command line option to
>> enable this as the default jboss logger implementation. I have not
>> tested it in quite a while so I don't know if t still works.
>>
>>
>>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
6:31 a.m.
Why do we keep having this thread over and over again
with ever new developer?
1) Use the jboss logger
JBoss has a very simple wrapper, as Jason and Scott explained.
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
* 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
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 :-)
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?
I'm sure this thread will appear again in 6 months when
the next new developer joins the project.
Logging always seems to be one of those flamebait topics,
I don't see why, it really isn't that interesting. :-)
On Wed, 2007-12-12 at 00:01 -0600, David M. Lloyd wrote:
What's the motivation behind this? Just dropping log4j? It
seems to
me that we'd want to provide some way for the tons of crap still using
log4j to still log to the log file properly.
- DML
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
9:04 a.m.
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
9:19 a.m.
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
9:27 a.m.
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
9:35 a.m.
(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
10:04 a.m.
The real problem is that VM vendors (JSR-47), rather than provide a
mechanism to plugin logging frameworks like log4j, took a detour and
provided us a "FINE, FINER, FINEST" mess. I do not see the folks behind
log4j on the expert committee of the JSR.
The only argument that David is providing is that an user has to have
multiple jars just for logging. Most of our projects have many jars
(oswego,Commons Logging,xb,common etc etc) as dependencies. Only JBAS
provides a common ground to develop applications anymore. :)
Projects like OpenSAML2 have started to use slf4j. If we are going to
integrate OSS projects, we have to provide support for their logging
choices. JBoss Logging provides the best abstraction at the moment.
Sacha Labourey wrote:
(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
10:18 a.m.
On Wed, 12 Dec 2007 09:04:11 -0600
Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
The real problem is that VM vendors (JSR-47), rather than provide a
mechanism to plugin logging frameworks like log4j, took a detour and
provided us a "FINE, FINER, FINEST" mess. I do not see the folks behind
log4j on the expert committee of the JSR.
Yes, but providing custom log levels is trivial. I do this to get back
DEBUG, TRACE, etc.
The only argument that David is providing is that an user has to have
multiple jars just for logging. Most of our projects have many jars
(oswego,Commons Logging,xb,common etc etc) as dependencies. Only JBAS
provides a common ground to develop applications anymore. :)
This is true. But you can't blame me for trying to minimize the mess.
Projects like OpenSAML2 have started to use slf4j. If we are going
to
integrate OSS projects, we have to provide support for their logging
choices. JBoss Logging provides the best abstraction at the moment.
Sure, but we could also try influencing their choices as well. SLF4J
is solving the same problem as JBoss logging, and clogging for that
matter. If everyone (or even the majority of projects) in the OSS world
were using one or the other (including us) then I'd have no problem
advocating that. But I don't see that happening - the only chance
there is for everyone to standardize on one logging API is to use the
one logging API that everyone is guaranteed to already have.
But none of that really matters in the big picture - we as a container
vendor should always have a LogManager installed anyway, because it's
not unreasonable for a developer to expect the standard logging
framework to function correctly -regardless- of our chosen logging
backend. I know I did when I first started using JBossAS.
And if we're already going to have a LogManager installed, then why not
just use JDK logging in our framework JARs?
- DML
Sacha Labourey wrote:
> (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
10:29 a.m.
On Dec 12, 2007, at 9:18 AM, David M. Lloyd wrote:
> Projects like OpenSAML2 have started to use slf4j. If we are going
> to
> integrate OSS projects, we have to provide support for their logging
> choices. JBoss Logging provides the best abstraction at the moment.
Sure, but we could also try influencing their choices as well.
Try to influence,
sure. But as I mentioned on the last thread (where
we discussed this same stuff), it is exceedingly arrogant to think
that you are going to affect a change in how all OSS projects do
logging just because you prefer one way or another.
By the nature of the game, containers are simply going to have to deal
with the consolidating logging from its bundled components through
various logging mechanisms.
9:42 a.m.
On Wed, 2007-12-12 at 08:27 -0600, David M. Lloyd wrote:
Well... honestly I don't know which bugs he's referring to.
Here's one only fixed in Java7:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638
Or this memory leak:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920
known about since 2003
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811930
Here's one of our workaround's so it doesn't stop
logging when you press ctrl-c
http://jira.jboss.com/jira/browse/JBAS-2087
etc.
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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:03 a.m.
On Wed, 12 Dec 2007 15:42:41 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
On Wed, 2007-12-12 at 08:27 -0600, David M. Lloyd wrote:
> Well... honestly I don't know which bugs he's referring to.
Here's one only fixed in Java7:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638
This one only applies to the default LogManager.
Or this memory leak:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920
This one too...
known about since 2003
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811930
This one too...
Here's one of our workaround's so it doesn't stop
logging when you press ctrl-c
http://jira.jboss.com/jira/browse/JBAS-2087
This one too.
etc.
> 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
10:38 a.m.
+100 to David on this.
The point here is about reducing number of dependencies. Another
meta-framework (like jboss common logging) is not a good solution IMHO.
This is particular important for OEMs who may want to use our project
embedded in their own applications (this is what we intend to do for JBM2)
If JDK logging can allow you to delegate to you log tool of choice by
deploy time configuration, and the bugs in JDK logging are only bugs in
the JDK logging implementation which you can bypass anyway, then we
should all be using JDK logging surely.
I'm certainly going to look at refactoring JBM to use JDK logging.
David M. Lloyd wrote:
On Wed, 12 Dec 2007 15:42:41 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
> On Wed, 2007-12-12 at 08:27 -0600, David M. Lloyd wrote:
>> Well... honestly I don't know which bugs he's referring to.
> Here's one only fixed in Java7:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638
This one only applies to the default LogManager.
> Or this memory leak:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920
This one too...
> known about since 2003
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811930
This one too...
> Here's one of our workaround's so it doesn't stop
> logging when you press ctrl-c
> http://jira.jboss.com/jira/browse/JBAS-2087
This one too.
> etc.
>
>> 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
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:48 a.m.
On Wed, 2007-12-12 at 15:38 +0000, Tim Fox wrote:
+100 to David on this.
It's a good job we do things based on merit rather than votes
at JBoss.
The point here is about reducing number of dependencies. Another
meta-framework (like jboss common logging) is not a good solution IMHO.
This is particular important for OEMs who may want to use our project
embedded in their own applications (this is what we intend to do for JBM2)
Irrelevant, they've already got to add jboss-messaging-client.jar
Reducing dependencies to me is just an excuse for NIH syndrome.
If JDK logging can allow you to delegate to you log tool of choice by
deploy time configuration, and the bugs in JDK logging are only bugs in
the JDK logging implementation which you can bypass anyway, then we
should all be using JDK logging surely.
I'm certainly going to look at refactoring JBM to use JDK logging.
And answer all the support cases, forum faqs and bug reports? :-)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:01 a.m.
Adrian Brock wrote:
On Wed, 2007-12-12 at 15:38 +0000, Tim Fox wrote:
> +100 to David on this.
>
It's a good job we do things based on merit rather than votes
at JBoss.
> The point here is about reducing number of dependencies. Another
> meta-framework (like jboss common logging) is not a good solution IMHO.
> This is particular important for OEMs who may want to use our project
> embedded in their own applications (this is what we intend to do for JBM2)
>
Irrelevant, they've already got to add jboss-messaging-client.jar
Reducing dependencies to me is just an excuse for NIH syndrome.
Huh? How is using JDK logging NIH syndrome? Seems the complete opposite.
Surely writing your own (jboss common logging) is NIH?
> If JDK logging can allow you to delegate to you log tool of choice by
> deploy time configuration, and the bugs in JDK logging are only bugs in
> the JDK logging implementation which you can bypass anyway, then we
> should all be using JDK logging surely.
>
> I'm certainly going to look at refactoring JBM to use JDK logging.
And answer all the support cases, forum faqs and bug reports? :-)
11:06 a.m.
On Wed, 2007-12-12 at 16:01 +0000, Tim Fox wrote:
Huh? How is using JDK logging NIH syndrome? Seems the complete
opposite.
Surely writing your own (jboss common logging) is NIH?
Read the discussion.
The proposal is to replace a 16k jar (that uses a simple
wrapper mechanism) with the following:
1) The use of JDK logging.
2) Rewriting all the log4j appenders (or at least
those that people find most useful) using the JDK api.
3) Subclasses of the JDK logger api (including some
unspecified factory api) to redirect to log4j
4) Persuade everybody else to use JDK logging
because we've implemented (2) and (3) in some JBoss
project.
5) Get Sun to fix/backport their bugs so we don't
have to use log4j (zero jar dependency logging)
6) Hope it is as stable as our current implementation
or (as David would have it) assume it is until
proven otherwise.
"Accordingly, I respectfully dissent." :-)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12:46 p.m.
Of course, I'm not suggesting that all the AS code be rewritten
overnight to use JUL, that would be a big task.
But IMHO it makes sense for new stuff, like what David or we are doing
in JBM to do this. I don't see any need for a big bang approach, this
could be factored in step by step without breaking anything.
Of course first we need to research the assertion that JUL delegation is
very buggy, which if true could be a showstopper.
Adrian Brock wrote:
On Wed, 2007-12-12 at 16:01 +0000, Tim Fox wrote:
> Huh? How is using JDK logging NIH syndrome? Seems the complete opposite.
>
> Surely writing your own (jboss common logging) is NIH?
Read the discussion.
The proposal is to replace a 16k jar (that uses a simple
wrapper mechanism) with the following:
1) The use of JDK logging.
2) Rewriting all the log4j appenders (or at least
those that people find most useful) using the JDK api.
3) Subclasses of the JDK logger api (including some
unspecified factory api) to redirect to log4j
4) Persuade everybody else to use JDK logging
because we've implemented (2) and (3) in some JBoss
project.
5) Get Sun to fix/backport their bugs so we don't
have to use log4j (zero jar dependency logging)
6) Hope it is as stable as our current implementation
or (as David would have it) assume it is until
proven otherwise.
"Accordingly, I respectfully dissent." :-)
12:57 p.m.
On Wed, 12 Dec 2007 17:06:04 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
On Wed, 2007-12-12 at 16:01 +0000, Tim Fox wrote:
> Huh? How is using JDK logging NIH syndrome? Seems the complete opposite.
>
> Surely writing your own (jboss common logging) is NIH?
Read the discussion.
The proposal is to replace a 16k jar (that uses a simple
wrapper mechanism) with the following:
Well, not exactly. Read my other mail for the actual changes I am
proposing...
5) Get Sun to fix/backport their bugs so we don't
have to use log4j (zero jar dependency logging)
Fix bugs yes - I don't really care if we use log4j in the appserver
though. That's Scott's thing. I just think we *shouldn't* be using log
facades in otherwise independent projects.
- DML
1:46 p.m.
On Wed, 2007-12-12 at 11:57 -0600, David M. Lloyd wrote:
On Wed, 12 Dec 2007 17:06:04 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
> On Wed, 2007-12-12 at 16:01 +0000, Tim Fox wrote:
> > Huh? How is using JDK logging NIH syndrome? Seems the complete opposite.
> >
> > Surely writing your own (jboss common logging) is NIH?
>
> Read the discussion.
>
> The proposal is to replace a 16k jar (that uses a simple
> wrapper mechanism) with the following:
Well, not exactly. Read my other mail for the actual changes I am
proposing...
But your proposal is for the appserver to do lots work
for what I will describe again as little more than a
aesthetic reason.
Quite frankly we've got better things to spend are
time on than writing, testing and supporting
a JUL->log4j adapter - even if it was technically possible
e.g. weaving all your classes that do Logger.getLogger()
to replace the implementation.
> 5) Get Sun to fix/backport their bugs so we don't
> have to use log4j (zero jar dependency logging)
Fix bugs yes - I don't really care if we use log4j in the appserver
though. That's Scott's thing. I just think we *shouldn't* be using log
facades in otherwise independent projects.
This is the part of the argument you just don't seem to be getting.
Just because you don't want to use a very simple facade,
others are forced to jump through hoops with more complicated
facades or accept a less than optimal solution.
Anyway, I'm done with this thread.
There's just no convincing some people.
Either you're not seeing the whole/bigger picture
"simple wrapper for you versus pain for some/everybody else"
or
"You cannot argue somebody out of a position using reason
if they never reasoned themselves into it in the
first place" :-)
- DML
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
2:10 p.m.
On Wed, 12 Dec 2007 19:46:17 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
But your proposal is for the appserver to do lots work
for what I will describe again as little more than a
aesthetic reason.
What about all the libraries and user programs that use JDK logging
today? Are we saying they're second-class citizens, and that they have
to configure a separate logging system? Even if I start using the
jboss logging facade right now, this problem still exists. Either
we're going to support them, and handle JDK logging, or they're SOL.
Quite frankly we've got better things to spend are
time on than writing, testing and supporting
a JUL->log4j adapter - even if it was technically possible
e.g. weaving all your classes that do Logger.getLogger()
to replace the implementation.
It doesn't have to be that complicated. Just installing a simple
LogManager would do the trick... I've even got one lying around
somewhere that does exactly this. It's not complicated.
This is the part of the argument you just don't seem to be
getting.
Just because you don't want to use a very simple facade,
others are forced to jump through hoops with more complicated
facades or accept a less than optimal solution.
I'm not forcing anyone to do anything, just saying we ought to support
JDK logging, which is not unreasonable I think.
"You cannot argue somebody out of a position using reason
if they never reasoned themselves into it in the
first place" :-)
OK.
Fact: we don't support JDK logging today in JBossAS.
Fact: it's simple to make an adapter LogManager for mapping JDK
logging to log4j.
Fact: There are libraries and user programs - even within JBossAS -
that use JDK logging today.
Is it so odd that I come to the conclusion that we should add support
for JDK logging? I'd even argue that, by providing a simplified
LogManager, we'd increase server stability by factoring out those bugs
mentioned earlier.
I don't think this is unreasonable.
- DML
11:10 a.m.
so, IF (and only IF), it is really possible to write a JUL logger that
has NO bug (i.e. exhibit no of the bugs Adrian is referring to - which
is something that still needs to be proved), then why don't we:
- move to JUL
- provide a default JUL logger that implements the actual JBoss logic i.e.
if (system property set)
use implementation of system property
else if (log4j in classpath)
use log4j
else
don't log
That way, we don't need an additional meta-framework but instead we
provide a logger that gives us flexibility. Again, only if this is
possible in a bug-free way ("bug-free" is a trademark of "JustDream,
Inc.")
On 12/12/2007 05:01 PM, Tim Fox wrote:
Adrian Brock wrote:
> On Wed, 2007-12-12 at 15:38 +0000, Tim Fox wrote:
>> +100 to David on this.
>>
>
> It's a good job we do things based on merit rather than votes
> at JBoss.
>
>> The point here is about reducing number of dependencies. Another
>> meta-framework (like jboss common logging) is not a good solution
>> IMHO. This is particular important for OEMs who may want to use our
>> project embedded in their own applications (this is what we intend to
>> do for JBM2)
>>
>
> Irrelevant, they've already got to add jboss-messaging-client.jar
>
> Reducing dependencies to me is just an excuse for NIH syndrome.
Huh? How is using JDK logging NIH syndrome? Seems the complete opposite.
Surely writing your own (jboss common logging) is NIH?
>
>> If JDK logging can allow you to delegate to you log tool of choice by
>> deploy time configuration, and the bugs in JDK logging are only bugs
>> in the JDK logging implementation which you can bypass anyway, then
>> we should all be using JDK logging surely.
>>
>> I'm certainly going to look at refactoring JBM to use JDK logging.
>
> And answer all the support cases, forum faqs and bug reports? :-)
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:40 p.m.
Sacha Labourey wrote:
so, IF (and only IF), it is really possible to write a JUL logger
that
has NO bug (i.e. exhibit no of the bugs Adrian is referring to - which
is something that still needs to be proved), then why don't we:
- move to JUL
- provide a default JUL logger that implements the actual JBoss logic i.e.
if (system property set)
use implementation of system property
else if (log4j in classpath)
use log4j
else
don't log
That way, we don't need an additional meta-framework but instead we
provide a logger that gives us flexibility. Again, only if this is
possible in a bug-free way ("bug-free" is a trademark of "JustDream,
Inc.")
+1. Yes exactly. If the JUL delegation is really just a simple
delegation there should be little scope for bugs, but this of course
needs to be investigated.
On 12/12/2007 05:01 PM, Tim Fox wrote:
>
>
> Adrian Brock wrote:
>> On Wed, 2007-12-12 at 15:38 +0000, Tim Fox wrote:
>>> +100 to David on this.
>>>
>>
>> It's a good job we do things based on merit rather than votes
>> at JBoss.
>>
>>> The point here is about reducing number of dependencies. Another
>>> meta-framework (like jboss common logging) is not a good solution
>>> IMHO. This is particular important for OEMs who may want to use our
>>> project embedded in their own applications (this is what we intend
>>> to do for JBM2)
>>>
>>
>> Irrelevant, they've already got to add jboss-messaging-client.jar
>>
>> Reducing dependencies to me is just an excuse for NIH syndrome.
>
> Huh? How is using JDK logging NIH syndrome? Seems the complete opposite.
>
> Surely writing your own (jboss common logging) is NIH?
>
>>
>>> If JDK logging can allow you to delegate to you log tool of choice
>>> by deploy time configuration, and the bugs in JDK logging are only
>>> bugs in the JDK logging implementation which you can bypass anyway,
>>> then we should all be using JDK logging surely.
>>>
>>> I'm certainly going to look at refactoring JBM to use JDK logging.
>>
>> And answer all the support cases, forum faqs and bug reports? :-)
>>
> _______________________________________________
> 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
11:15 a.m.
While we work of coaxing all OSS projects that JBoss is concerned with,
to use JDK logging, can we also work on Global Warming and Ending World
Hunger. This is because we can get it done in the same time frame. :)
Pray, tell me about JDK logging configuration. If I want to introduce
xml based configuration instead of the default properties file based
setup, do I need a plugin?
Tim Fox wrote:
+100 to David on this.
The point here is about reducing number of dependencies. Another
meta-framework (like jboss common logging) is not a good solution
IMHO. This is particular important for OEMs who may want to use our
project embedded in their own applications (this is what we intend to
do for JBM2)
If JDK logging can allow you to delegate to you log tool of choice by
deploy time configuration, and the bugs in JDK logging are only bugs
in the JDK logging implementation which you can bypass anyway, then we
should all be using JDK logging surely.
I'm certainly going to look at refactoring JBM to use JDK logging.
David M. Lloyd wrote:
> On Wed, 12 Dec 2007 15:42:41 +0100
> Adrian Brock <abrock(a)redhat.com> wrote:
>
>> On Wed, 2007-12-12 at 08:27 -0600, David M. Lloyd wrote:
>>> Well... honestly I don't know which bugs he's referring to.
>> Here's one only fixed in Java7:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6487638
>
> This one only applies to the default LogManager.
>
>> Or this memory leak:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920
>
> This one too...
>
>> known about since 2003
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4811930
>
> This one too...
>
>> Here's one of our workaround's so it doesn't stop
>> logging when you press ctrl-c
>> http://jira.jboss.com/jira/browse/JBAS-2087
>
> This one too.
>
>> etc.
>>
>>> 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
3:04 a.m.
Tim Fox wrote:
+100 to David on this.
The point here is about reducing number of dependencies. Another
meta-framework (like jboss common logging) is not a good solution
IMHO. This is particular important for OEMs who may want to use our
project embedded in their own applications (this is what we intend to
do for JBM2)
If JDK logging can allow you to delegate to you log tool of choice by
deploy time configuration, and the bugs in JDK logging are only bugs
in the JDK logging implementation which you can bypass anyway, then we
should all be using JDK logging surely.
I'm certainly going to look at refactoring JBM to use JDK logging.
Me too. If Adrian and/or Scott can tell me that this will not cause
issues in the appserver because they can wrap/redirect my calls to JUL
to log4j (or their own logging impl), then that would be fine. Otherwise
I'd probably wait for JDK 7
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
3 p.m.
The main problem I have had with JUL integration in the past is that it
requires hooking into the core configuration at the extension classpath
level. I had to replace the JUL manager to allow for configurations that
loaded loggers from application/thread context class loaders. Not that
this is hard, its just something that has to be part of the server
bootstrap process rather than something that can be done via late binding.
Its been a while since I looked at integration though. With the other
mega-thread about i18n/JUL integration, we need some tasks to
investigate what we can/want to do in terms of allowing seamless
integration from framework JUL usage to be mapped to server loggers, and
what the jboss logging spi is.
Bela Ban wrote:
Tim Fox wrote:
> +100 to David on this.
>
> The point here is about reducing number of dependencies. Another
> meta-framework (like jboss common logging) is not a good solution
> IMHO. This is particular important for OEMs who may want to use our
> project embedded in their own applications (this is what we intend to
> do for JBM2)
>
> If JDK logging can allow you to delegate to you log tool of choice by
> deploy time configuration, and the bugs in JDK logging are only bugs
> in the JDK logging implementation which you can bypass anyway, then we
> should all be using JDK logging surely.
>
> I'm certainly going to look at refactoring JBM to use JDK logging.
Me too. If Adrian and/or Scott can tell me that this will not cause
issues in the appserver because they can wrap/redirect my calls to JUL
to log4j (or their own logging impl), then that would be fine. Otherwise
I'd probably wait for JDK 7
8:19 p.m.
I think David just volunteered.... Right David???
Scott M Stark wrote:
The main problem I have had with JUL integration in the past is that
it
requires hooking into the core configuration at the extension classpath
level. I had to replace the JUL manager to allow for configurations that
loaded loggers from application/thread context class loaders. Not that
this is hard, its just something that has to be part of the server
bootstrap process rather than something that can be done via late binding.
Its been a while since I looked at integration though. With the other
mega-thread about i18n/JUL integration, we need some tasks to
investigate what we can/want to do in terms of allowing seamless
integration from framework JUL usage to be mapped to server loggers, and
what the jboss logging spi is.
Bela Ban wrote:
>
> Tim Fox wrote:
>> +100 to David on this.
>>
>> The point here is about reducing number of dependencies. Another
>> meta-framework (like jboss common logging) is not a good solution
>> IMHO. This is particular important for OEMs who may want to use our
>> project embedded in their own applications (this is what we intend to
>> do for JBM2)
>>
>> If JDK logging can allow you to delegate to you log tool of choice by
>> deploy time configuration, and the bugs in JDK logging are only bugs
>> in the JDK logging implementation which you can bypass anyway, then we
>> should all be using JDK logging surely.
>>
>> I'm certainly going to look at refactoring JBM to use JDK logging.
> Me too. If Adrian and/or Scott can tell me that this will not cause
> issues in the appserver because they can wrap/redirect my calls to JUL
> to log4j (or their own logging impl), then that would be fine. Otherwise
> I'd probably wait for JDK 7
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Jason T. Greene
JBoss, a division of Red Hat
10:43 p.m.
I created a simple log manager that could be the basis for... something.
The URL is: https://svn.jboss.org/repos/sandbox/david.lloyd/logmanager
It's just four classes - one of which is a copy of the WeakValueHashMap
class from jboss common core, relocated to the other package. Though in
practice one could just depend on that project; this is just for the
sake of illustration.
Anyway, features of this minimalist log manager:
* Every node in the logger heirarchy holds only weak references to its
children (solves Sun bugs 4811930, 6274920)
* There's no configuration whatsoever (solves JBAS-2087)
* LogManager.addLogger() is a no-op (always returns false) (solves Sun
bug 6487638)
* The stupid class/method inferring crap in LogRecord is suppressed
* Late binding is simple - just add a Handler to the root logger
whenever you like
Other things that could be done:
* Add security permissions such that an application can configure or
get loggers for only sections of the global heirarchy (allows
applications to add Handlers for their log messages, but not "steal"
messages for applications or components that they don't have permission
to) - this would be pretty easy I think
* Dunno, probably other cool stuff
Notes:
* The log manager disallows getting a complete listing of Loggers -
call this a security feature if you like :-)
* LogManager.getLogger(xxx) always returns a Logger, even if one didn't
exist before
Anyway, comment if you like.
On Thu, 13 Dec 2007 12:00:50 -0800
Scott M Stark <sstark(a)redhat.com> wrote:
The main problem I have had with JUL integration in the past is that
it
requires hooking into the core configuration at the extension classpath
level. I had to replace the JUL manager to allow for configurations that
loaded loggers from application/thread context class loaders. Not that
this is hard, its just something that has to be part of the server
bootstrap process rather than something that can be done via late binding.
Its been a while since I looked at integration though. With the other
mega-thread about i18n/JUL integration, we need some tasks to
investigate what we can/want to do in terms of allowing seamless
integration from framework JUL usage to be mapped to server loggers, and
what the jboss logging spi is.
Bela Ban wrote:
>
>
> Tim Fox wrote:
>> +100 to David on this.
>>
>> The point here is about reducing number of dependencies. Another
>> meta-framework (like jboss common logging) is not a good solution
>> IMHO. This is particular important for OEMs who may want to use our
>> project embedded in their own applications (this is what we intend to
>> do for JBM2)
>>
>> If JDK logging can allow you to delegate to you log tool of choice by
>> deploy time configuration, and the bugs in JDK logging are only bugs
>> in the JDK logging implementation which you can bypass anyway, then we
>> should all be using JDK logging surely.
>>
>> I'm certainly going to look at refactoring JBM to use JDK logging.
>
> Me too. If Adrian and/or Scott can tell me that this will not cause
> issues in the appserver because they can wrap/redirect my calls to JUL
> to log4j (or their own logging impl), then that would be fine. Otherwise
> I'd probably wait for JDK 7
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
11 p.m.
New subject: A simple logmanager implementation [Was: Re: My logging ultimatum]
Forgot that not everyone is a committer, so...
Anonymous SVN link: http://anonsvn.jboss.org/repos/sandbox/david.lloyd/logmanager
- DML
On Thu, 13 Dec 2007 21:43:33 -0600 "David M. Lloyd"
<david.lloyd(a)redhat.com> wrote:
I created a simple log manager that could be the basis for...
something.
The URL is: https://svn.jboss.org/repos/sandbox/david.lloyd/logmanager
It's just four classes - one of which is a copy of the WeakValueHashMap
class from jboss common core, relocated to the other package. Though in
practice one could just depend on that project; this is just for the
sake of illustration.
Anyway, features of this minimalist log manager:
* Every node in the logger heirarchy holds only weak references to its
children (solves Sun bugs 4811930, 6274920)
* There's no configuration whatsoever (solves JBAS-2087)
* LogManager.addLogger() is a no-op (always returns false) (solves Sun
bug 6487638)
* The stupid class/method inferring crap in LogRecord is suppressed
* Late binding is simple - just add a Handler to the root logger
whenever you like
Other things that could be done:
* Add security permissions such that an application can configure or
get loggers for only sections of the global heirarchy (allows
applications to add Handlers for their log messages, but not "steal"
messages for applications or components that they don't have permission
to) - this would be pretty easy I think
* Dunno, probably other cool stuff
Notes:
* The log manager disallows getting a complete listing of Loggers -
call this a security feature if you like :-)
* LogManager.getLogger(xxx) always returns a Logger, even if one didn't
exist before
Anyway, comment if you like.
On Thu, 13 Dec 2007 12:00:50 -0800
Scott M Stark <sstark(a)redhat.com> wrote:
> The main problem I have had with JUL integration in the past is that it
> requires hooking into the core configuration at the extension classpath
> level. I had to replace the JUL manager to allow for configurations that
> loaded loggers from application/thread context class loaders. Not that
> this is hard, its just something that has to be part of the server
> bootstrap process rather than something that can be done via late binding.
>
> Its been a while since I looked at integration though. With the other
> mega-thread about i18n/JUL integration, we need some tasks to
> investigate what we can/want to do in terms of allowing seamless
> integration from framework JUL usage to be mapped to server loggers, and
> what the jboss logging spi is.
>
> Bela Ban wrote:
> >
> >
> > Tim Fox wrote:
> >> +100 to David on this.
> >>
> >> The point here is about reducing number of dependencies. Another
> >> meta-framework (like jboss common logging) is not a good solution
> >> IMHO. This is particular important for OEMs who may want to use our
> >> project embedded in their own applications (this is what we intend to
> >> do for JBM2)
> >>
> >> If JDK logging can allow you to delegate to you log tool of choice by
> >> deploy time configuration, and the bugs in JDK logging are only bugs
> >> in the JDK logging implementation which you can bypass anyway, then we
> >> should all be using JDK logging surely.
> >>
> >> I'm certainly going to look at refactoring JBM to use JDK logging.
> >
> > Me too. If Adrian and/or Scott can tell me that this will not cause
> > issues in the appserver because they can wrap/redirect my calls to JUL
> > to log4j (or their own logging impl), then that would be fine. Otherwise
> > I'd probably wait for JDK 7
> >
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
9:20 a.m.
You still miss the point. I'm not wrong. :-)
Forcing people to use the JDK api (broken)
because you don't like 3 jars (working)
isn't a solution to the problem.
The deadlocking problems can only get worse
in the delegating LogManager solution.
You now have competing synchronization
strategies, e.g. jdk and log4j
Conclusion: An unstable server is not a valid
trade-off to fix some aethestic considersation
about distributing a few small jars.
On Wed, 2007-12-12 at 08:04 -0600, 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
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
10:01 a.m.
On Wed, 12 Dec 2007 15:20:12 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
You still miss the point. I'm not wrong. :-)
Forcing people to use the JDK api (broken)
because you don't like 3 jars (working)
isn't a solution to the problem.
Sure it is, assuming that the JDK api isn't broken, or at least not
unfixably so.
The deadlocking problems can only get worse
in the delegating LogManager solution.
You now have competing synchronization
strategies, e.g. jdk and log4j
What deadlocking problems? What strategies? If you do a custom
LogManager, there *is* no synchronization strategy as far as I see -
you're completely in control. Has it been demonstrated that the JDK api
is broken?
Conclusion: An unstable server is not a valid
trade-off to fix some aethestic considersation
about distributing a few small jars.
Sure I'll agree with that, but as far as I can see it hasn't been
demonstrated that JDK logging would make your server unstable. Also,
calling JAR dependencies "small" and "aesthetic" is really your
opinion, not a factual contribution to the discussion.
On Wed, 2007-12-12 at 08:04 -0600, 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
10:34 a.m.
On Wed, 2007-12-12 at 09:01 -0600, David M. Lloyd wrote:
On Wed, 12 Dec 2007 15:20:12 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
> You still miss the point. I'm not wrong. :-)
>
> Forcing people to use the JDK api (broken)
> because you don't like 3 jars (working)
> isn't a solution to the problem.
Sure it is, assuming that the JDK api isn't broken, or at least not
unfixably so.
Assumptions...
The devil is always in the details. :-)
> The deadlocking problems can only get worse
> in the delegating LogManager solution.
> You now have competing synchronization
> strategies, e.g. jdk and log4j
What deadlocking problems? What strategies? If you do a custom
LogManager, there *is* no synchronization strategy as far as I see -
you're completely in control. Has it been demonstrated that the JDK api
is broken?
See other post for two examples of "unfixed bugs".
Implementing the whole LogManager/Logger api
is almost certainly more code than jboss-logging-spi
and you'd need a seperate (non jdk) api to create something other
than the default logger implementation.
// static method == not overriddable
private static final Logger log = Logger.getLogger(className)
Your only reason for doing it is so you can have a
zero jar deployment (i.e. use the JDK by default)
but this is potentially broken as demonstrated.
In fact, this changes the burden for clients.
Previously a client without log4j or a log4j configuration
did no logging,
Now they will have to do some configuration
to avoid the potentially broken JDK calls.
> Conclusion: An unstable server is not a valid
> trade-off to fix some aethestic considersation
> about distributing a few small jars.
Sure I'll agree with that, but as far as I can see it hasn't been
demonstrated that JDK logging would make your server unstable.
We've had lots of problems with logging causing server hangs
in the past.
Logging is pervasive, it's not something
we should be changing on a whim.
And the correct question is the opposite:
"Is JDK logging demostratively as stable as what we've got now?"
Also,
calling JAR dependencies "small" and "aesthetic" is really your
opinion, not a factual contribution to the discussion.
And that there is a real problem that needs solving here
is your opinion.
You are arguing for a change, convince me
that a "few extra" java classes on the classpath
is a big problem that requires this "major upheaval".
(opinions in quotes :-).
P.S. Attacking my argument as only opinion is
a logical fallacy:
http://en.wikipedia.org/wiki/Ignoratio_elenchi
and certainly not a "factual contribution to the discussion". :-)
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11:19 a.m.
On Wed, 12 Dec 2007 16:34:00 +0100
Adrian Brock <abrock(a)redhat.com> wrote:
Assumptions...
The devil is always in the details. :-)
My point being that calling it broken without citing examples doesn't
help the discussion - but, since then, you've done so. So, moving
onward...
> > The deadlocking problems can only get worse
> > in the delegating LogManager solution.
> > You now have competing synchronization
> > strategies, e.g. jdk and log4j
>
> What deadlocking problems? What strategies? If you do a custom
> LogManager, there *is* no synchronization strategy as far as I see -
> you're completely in control. Has it been demonstrated that the JDK api
> is broken?
See other post for two examples of "unfixed bugs".
Implementing the whole LogManager/Logger api
is almost certainly more code than jboss-logging-spi
and you'd need a seperate (non jdk) api to create something other
than the default logger implementation.
Yes, this is true, but these are two different situations.
// static method == not overriddable
private static final Logger log = Logger.getLogger(className)
Fair point... But the Logger.getLogger() method (and the corresponding
LogManager.demandLogger() method) are the only bits that an implementer
would not have full control over. It's not too hard to work around.
Your only reason for doing it is so you can have a
zero jar deployment (i.e. use the JDK by default)
but this is potentially broken as demonstrated.
In fact, this changes the burden for clients.
Previously a client without log4j or a log4j configuration
did no logging,
Now they will have to do some configuration
to avoid the potentially broken JDK calls.
If a user is using a container of nearly any sort (well, except for
ours), then using JDK logging will go to the server log. If the user
is running standalone, then they still have a choice - include zero
jars (and get logs on System.err) or include one jar to get whatever
the logging behavior it is that they're after. I don't see this as any
better or worse than always requiring one jar and getting no logs -
they could always just include a jdk-logging-null.jar and get the same
thing.
>
> > Conclusion: An unstable server is not a valid
> > trade-off to fix some aethestic considersation
> > about distributing a few small jars.
>
> Sure I'll agree with that, but as far as I can see it hasn't been
> demonstrated that JDK logging would make your server unstable.
We've had lots of problems with logging causing server hangs
in the past.
Logging is pervasive, it's not something
we should be changing on a whim.
And the correct question is the opposite:
"Is JDK logging demostratively as stable as what we've got now?"
I'm not advocating to change the logging backend on the server - that's
what Scott has done with his change, which has nothing to do with what
I propose.
I am proposing the following changes, and nothing more:
1) Always provide support on JBossAS for libraries and user code that
use JDK logging, which forwards log messages into the server log. This
means install a LogManager. If we want to continue to use log4j, we
should use a LogManager that forwards to log4j. Anything intrinsic to
the container should continue to use the JBoss common logging framework
without any change, which works just fine for that purpose.
2) Always provide support on JBossAS for libraries and user code that
use log4j. If we drop log4j, then we should continue to provide an
emulation API or something, because there are clearly lots of things
that still use it.
3) People developing new libraries or JBoss.org projects or whatever
should at least *consider* using JDK logging if they need to log
messages. Or, if the objection to JDK logging is insurmountable, then
at least make the logging framework optional somehow. Though I believe
that JDK logging can be used as a viable alternative to clogging and
friends.
You are arguing for a change, convince me
that a "few extra" java classes on the classpath
is a big problem that requires this "major upheaval".
(opinions in quotes :-).
Heh, well it doesn't -require- major upheaval per se, that's just the
kind of guy I am. I just can't wake up in the morning without some
kind of major upheaval.
P.S. Attacking my argument as only opinion is
a logical fallacy:
http://en.wikipedia.org/wiki/Ignoratio_elenchi
and certainly not a "factual contribution to the discussion". :-)
Fair.
- DML
8:56 a.m.
Bela Ban wrote:
David M. Lloyd wrote:
> The fact is, zero JARs is better than one, no matter how small it is.
+1000. I hope to ship only jgroups.jar some day. And I hope that day
will come before I retire... :-)
Having one jar is awesome. You can do that today though, even with deps!
http://code.google.com/p/jarjar/
--
Jason T. Greene
JBoss, a division of Red Hat
9:10 a.m.
Why don't we do this for JBossCache and PojoCache (with quite some deps)
already ?
Because the embeded JARs might conflict with the user's copies
(different versions) ?
BTW: I'm really looking forward to Java 7's java feature which let's you
list directories with JARs, rather than the individual JARs
Jason T. Greene wrote:
Bela Ban wrote:
>
>
> David M. Lloyd wrote:
>> The fact is, zero JARs is better than one, no matter how small it is.
>
> +1000. I hope to ship only jgroups.jar some day. And I hope that day
> will come before I retire... :-)
>
Having one jar is awesome. You can do that today though, even with deps!
http://code.google.com/p/jarjar/
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat
9:24 a.m.
New subject: JarJar for JBoss Cache/ PojoCache [WAS:] My logging ultimatum
If you guys go that route, please provide a clean version for AS
integration.
Bela Ban wrote:
Why don't we do this for JBossCache and PojoCache (with quite
some deps)
already ?
Because the embeded JARs might conflict with the user's copies
(different versions) ?
BTW: I'm really looking forward to Java 7's java feature which let's you
list directories with JARs, rather than the individual JARs
Jason T. Greene wrote:
> Bela Ban wrote:
>>
>>
>> David M. Lloyd wrote:
>>> The fact is, zero JARs is better than one, no matter how small it is.
>>
>> +1000. I hope to ship only jgroups.jar some day. And I hope that day
>> will come before I retire... :-)
>>
>
> Having one jar is awesome. You can do that today though, even with deps!
>
> http://code.google.com/p/jarjar/
>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
9:34 a.m.
Bela Ban wrote:
Why don't we do this for JBossCache and PojoCache (with quite
some deps)
already ?
We could look at it. There are 2 disadvantages to doing it:
1) License compatibility (have to make sure deps have compatible licenses)
2) A fatter jar
Because the embeded JARs might conflict with the user's copies
(different versions) ?
It solves this by doing package translation. For example org.apache.foo
becomes org.jgroups.thirdparty.foo.
BTW: I'm really looking forward to Java 7's java feature
which let's you
list directories with JARs, rather than the individual JARs
Amen. Something that should have been there long ago.
Jason T. Greene wrote:
> Bela Ban wrote:
>>
>>
>> David M. Lloyd wrote:
>>> The fact is, zero JARs is better than one, no matter how small it is.
>>
>> +1000. I hope to ship only jgroups.jar some day. And I hope that day
>> will come before I retire... :-)
>>
>
> Having one jar is awesome. You can do that today though, even with deps!
>
> http://code.google.com/p/jarjar/
>
--
Jason T. Greene
JBoss, a division of Red Hat
2:37 p.m.
This does not work for libraries like commons-logging that have
factories loading resources commons-logging.properties. You have to also
change the resource name and package names used there.
Bela Ban wrote:
Why don't we do this for JBossCache and PojoCache (with quite
some deps)
already ?
Because the embeded JARs might conflict with the user's copies
(different versions) ?
BTW: I'm really looking forward to Java 7's java feature which let's you
list directories with JARs, rather than the individual JARs
Jason T. Greene wrote:
> Bela Ban wrote:
>>
>>
>> David M. Lloyd wrote:
>>> The fact is, zero JARs is better than one, no matter how small it is.
>>
>> +1000. I hope to ship only jgroups.jar some day. And I hope that day
>> will come before I retire... :-)
>>
>
> Having one jar is awesome. You can do that today though, even with deps!
>
> http://code.google.com/p/jarjar/
>
10:23 a.m.
Just a clarification, Hibernate now uses slf4j instead of jcl...
On Dec 12, 2007, at 5:31 AM, Adrian Brock wrote:
Why do we keep having this thread over and over again
with ever new developer?
1) Use the jboss logger
JBoss has a very simple wrapper, as Jason and Scott explained.
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
* 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
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 :-)
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?
I'm sure this thread will appear again in 6 months when
the next new developer joins the project.
Logging always seems to be one of those flamebait topics,
I don't see why, it really isn't that interesting. :-)
On Wed, 2007-12-12 at 00:01 -0600, David M. Lloyd wrote:
> What's the motivation behind this? Just dropping log4j? It seems to
> me that we'd want to provide some way for the tons of crap still
> using
> log4j to still log to the log file properly.
>
> - DML
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:45 p.m.
On Dec 11, 2007 6:00 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
* The JBossAS logging system must be changed such that BY DEFAULT
log
messages are all handled properly (in terms of category and level),
regardless of the logging framework used (java.util.logging or log4j).
No, relying on the System.out/System.err capture mechanism is NOT
sufficient for this task. This means that, as far as I can tell, we
should always be installing a JUL LogManger on appserver startup.
Frankly it really baffles and disappoints me that 4.0.x and 4.2.x didn't
do this out of the box.
I have a LogManager that uses the context CL to find its configuration
and isolate logging:
http://anonsvn.jboss.org/repos/jbossweb/trunk/java/org/apache/juli/ClassL...
It could be used as a starting point or for some ideas.
Rémy
5975
days inactive
5978
days old
jboss-development@lists.jboss.org
54 comments
12 participants
participants (12)
-
Adrian Brock -
Anil Saldhana -
Bela Ban -
Brian Stansberry -
David M. Lloyd -
Jason T. Greene -
Rémy Maucherat -
Sacha Labourey -
Scott M Stark -
Scott Stark
-
Steve Ebersole -
Tim Fox