3:08 p.m.
I am considering moving Hibernate to use slf4j instead of commons-logging. I
had been considering moving to straight log4j usage anyway to get MDC/NDC
capability, but slf4j just added this capability. So it now has all the
capabilities I need.
Just curious whether anyone has seen it used within JBoss AS and what the
experiences were.
3:17 p.m.
On 7/5/07, Steve Ebersole <steve(a)hibernate.org> wrote:
I am considering moving Hibernate to use slf4j instead of
commons-logging. I
had been considering moving to straight log4j usage anyway to get MDC/NDC
capability, but slf4j just added this capability. So it now has all the
capabilities I need.
Just curious whether anyone has seen it used within JBoss AS and what the
experiences were.
It is natural IMO that this facade exposes features from log4j since
the author is the same. Personally, I try to avoid log4j at all costs,
since it is by design less robust than java.util.logging
(java.util.logging is using a singleton design, and lives in the JVM
classloader, so there cannot be any class conflicts).
Rémy
3:23 p.m.
On Thursday 05 July 2007 08:17:53 am Rémy Maucherat wrote:
On 7/5/07, Steve Ebersole <steve(a)hibernate.org> wrote:
> I am considering moving Hibernate to use slf4j instead of
> commons-logging. I had been considering moving to straight log4j usage
> anyway to get MDC/NDC capability, but slf4j just added this capability.
> So it now has all the capabilities I need.
>
> Just curious whether anyone has seen it used within JBoss AS and what the
> experiences were.
It is natural IMO that this facade exposes features from log4j since
the author is the same. Personally, I try to avoid log4j at all costs,
since it is by design less robust than java.util.logging
(java.util.logging is using a singleton design, and lives in the JVM
classloader, so there cannot be any class conflicts).
Rémy
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
Thanks, Remy.
Yes, and it lacks any kind of diagnostic context support. Sure, I know I
could build it on top of whatever log framework I end up using; but then I am
writing a logging framework myself...
Yes, I know Ceki writes slf4j. I had a dialog with him about adding this MDC
support.
Have you seen cases of slf4j usage in Tomcat?
3:32 p.m.
On 7/5/07, Steve Ebersole <steve(a)hibernate.org> wrote:
Yes, and it lacks any kind of diagnostic context support. Sure, I
know I
could build it on top of whatever log framework I end up using; but then I am
writing a logging framework myself...
This thread local functionality can usually be built up very easily:
you need a custom formatter of some sort for the logging messages (all
logging frameworks allow this kind of stuff AFAIK), and a few calls to
set the thread local fields. There's no need to implement a whole
logging framework ;)
In JBoss, the reliability problems are hidden thanks to the
classloading strategy, but in a more conventional hierarchy (like in
Tomcat), it breaks very easily.
Yes, I know Ceki writes slf4j. I had a dialog with him about adding
this MDC
support.
Have you seen cases of slf4j usage in Tomcat?
The default Tomcat configuration uses common-logging with
java.util.logging configured with a custom LogManager I wrote
(otherwise, JUL is totally useless in a container environment).
Rémy
4:53 p.m.
In JBoss, the reliability problems are hidden thanks to the
classloading strategy, but in a more conventional hierarchy (like in
Tomcat), it breaks very easily.
Is that a compliment for our classloading model? :-)
There was a related discussion about nlog4j here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67835
5:01 p.m.
that's the new commercial slogan for the UCL:
"UCL, the classloader that fixes your Log4j problems"
On 5 juil. 07, at 16:53, Dimitris Andreadis wrote:
> In JBoss, the reliability problems are hidden thanks to the
> classloading strategy, but in a more conventional hierarchy (like in
> Tomcat), it breaks very easily.
Is that a compliment for our classloading model? :-)
There was a related discussion about nlog4j here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67835
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
Julien Viet
JBoss Portal Project Lead
Red Hat Inc.
http://jbossportal.blogspot.com/
Red Hat France SARL, 171 Avenue Georges Clemenceau, 92024 Nanterre
Cedex, France.
Siret n° 421 199 464 00056
6:01 p.m.
On Thu, 2007-07-05 at 15:17 +0200, Rémy Maucherat wrote:
On 7/5/07, Steve Ebersole <steve(a)hibernate.org> wrote:
> I am considering moving Hibernate to use slf4j instead of commons-logging. I
> had been considering moving to straight log4j usage anyway to get MDC/NDC
> capability, but slf4j just added this capability. So it now has all the
> capabilities I need.
>
> Just curious whether anyone has seen it used within JBoss AS and what the
> experiences were.
It is natural IMO that this facade exposes features from log4j since
the author is the same. Personally, I try to avoid log4j at all costs,
since it is by design less robust than java.util.logging
(java.util.logging is using a singleton design, and lives in the JVM
classloader, so there cannot be any class conflicts).
I think you'll find the "no conflicts" has more to do with the fact
that you can't load a class that begins in "java." outside
the bootstrap classloader.
This has nothing to do with "design". You could define
similar rules in other classloaders.
Rémy
_______________________________________________
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
7:29 p.m.
On Thursday 05 July 2007 08:08:02 am Steve Ebersole wrote:
I am considering moving Hibernate to use slf4j instead of
commons-logging.
I had been considering moving to straight log4j usage anyway to get MDC/NDC
capability, but slf4j just added this capability. So it now has all the
capabilities I need.
Just curious whether anyone has seen it used within JBoss AS and what the
experiences were.
So then back to my original question... ;)
I guess noone has any compliants (or no experiences) with slf4j?
8:25 p.m.
No, as I was loathe to introduce yet another logging wrapper.
Steve Ebersole wrote:
On Thursday 05 July 2007 08:08:02 am Steve Ebersole wrote:
> I am considering moving Hibernate to use slf4j instead of commons-logging.
> I had been considering moving to straight log4j usage anyway to get MDC/NDC
> capability, but slf4j just added this capability. So it now has all the
> capabilities I need.
>
> Just curious whether anyone has seen it used within JBoss AS and what the
> experiences were.
So then back to my original question... ;)
I guess noone has any compliants (or no experiences) with slf4j?
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
8:52 p.m.
slf4j is the parent of nlog4j and now all development has moved into
http://logback.com Where does the linking end?
If we are doing MINA, then it uses slf4j.
Scott M Stark wrote:
No, as I was loathe to introduce yet another logging wrapper.
Steve Ebersole wrote:
> On Thursday 05 July 2007 08:08:02 am Steve Ebersole wrote:
>
>> I am considering moving Hibernate to use slf4j instead of commons-logging.
>> I had been considering moving to straight log4j usage anyway to get MDC/NDC
>> capability, but slf4j just added this capability. So it now has all the
>> capabilities I need.
>>
>> Just curious whether anyone has seen it used within JBoss AS and what the
>> experiences were.
>>
> So then back to my original question... ;)
>
> I guess noone has any compliants (or no experiences) with slf4j?
> _______________________________________________
> 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
--
Anil Saldhana
Project/Technical Lead,
JBoss Security & Identity Management
JBoss, A division of Red Hat Inc.
http://labs.jboss.com/portal/jbosssecurity/
8:55 p.m.
"Logback is intended as a successor to the popular log4j project. It
was designed by Ceki Gülcü, the founder of the log4j project. It
builds upon exerience gained in building industrial-strength logging
systems going back as far as 1999."
after 8 years of doing logging I hope he has a good experience of
what logging is :-)
On 5 juil. 07, at 20:52, Anil Saldhana wrote:
slf4j is the parent of nlog4j and now all development has moved
into http://logback.com Where does the linking end?
If we are doing MINA, then it uses slf4j.
Scott M Stark wrote:
> No, as I was loathe to introduce yet another logging wrapper.
>
> Steve Ebersole wrote:
>
>> On Thursday 05 July 2007 08:08:02 am Steve Ebersole wrote:
>>
>>> I am considering moving Hibernate to use slf4j instead of
>>> commons-logging. I had been considering moving to straight log4j
>>> usage anyway to get MDC/NDC
>>> capability, but slf4j just added this capability. So it now has
>>> all the
>>> capabilities I need.
>>>
>>> Just curious whether anyone has seen it used within JBoss AS and
>>> what the
>>> experiences were.
>>>
>> So then back to my original question... ;)
>>
>> I guess noone has any compliants (or no experiences) with slf4j?
>> _______________________________________________
>> 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
>
--
Anil Saldhana
Project/Technical Lead,
JBoss Security & Identity Management
JBoss, A division of Red Hat Inc.
http://labs.jboss.com/portal/jbosssecurity/
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
Julien Viet
JBoss Portal Project Lead
Red Hat Inc.
http://jbossportal.blogspot.com/
Red Hat France SARL, 171 Avenue Georges Clemenceau, 92024 Nanterre
Cedex, France.
Siret n° 421 199 464 00056
9:09 p.m.
On 7/5/07, Julien Viet <julien(a)jboss.com> wrote:
"Logback is intended as a successor to the popular log4j
project. It
was designed by Ceki Gülcü, the founder of the log4j project. It
builds upon exerience gained in building industrial-strength logging
systems going back as far as 1999."
after 8 years of doing logging I hope he has a good experience of
what logging is :-)
Yet, I don't like his APIs and stuff, I always liked j.util.logging
better. The pluggability is very good, and it remains robust. I've
read statements from Ceki that logging shouldn't be causing an
application to fail, but that's clearly not the case with log4j (if
that was the case, there would be try/catch throwables in the code).
Rémy
9:35 a.m.
It can be confusing. When I looked at it some time ago I noted down:
slf4j is the logging facade, that can have back-ends:
- nop
- simple logger
- java.util.logging
- log4j
- logback (former nlog4j, successor to log4j)
Then there are the drop-in replacement libraries:
a) jcl104-over-slf4j, drop-in replacement for Jakarta Commons Logging over slf4j
b) log4j-over-slf4j, drop-in replacement for log4j over slf4j
It seems you can have all sorts of combinations.
Julien Viet wrote:
"Logback is intended as a successor to the popular log4j
project. It was
designed by Ceki Gülcü, the founder of the log4j project. It builds upon
exerience gained in building industrial-strength logging systems going
back as far as 1999."
after 8 years of doing logging I hope he has a good experience of what
logging is :-)
On 5 juil. 07, at 20:52, Anil Saldhana wrote:
> slf4j is the parent of nlog4j and now all development has moved into
> http://logback.com Where does the linking end?
>
> If we are doing MINA, then it uses slf4j.
>
> Scott M Stark wrote:
>> No, as I was loathe to introduce yet another logging wrapper.
>>
>> Steve Ebersole wrote:
>>
>>> On Thursday 05 July 2007 08:08:02 am Steve Ebersole wrote:
>>>
>>>> I am considering moving Hibernate to use slf4j instead of
>>>> commons-logging. I had been considering moving to straight log4j
>>>> usage anyway to get MDC/NDC
>>>> capability, but slf4j just added this capability. So it now has
>>>> all the
>>>> capabilities I need.
>>>>
>>>> Just curious whether anyone has seen it used within JBoss AS and
>>>> what the
>>>> experiences were.
>>>>
>>> So then back to my original question... ;)
>>>
>>> I guess noone has any compliants (or no experiences) with slf4j?
>>> _______________________________________________
>>> 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
>>
>
> --
> Anil Saldhana
> Project/Technical Lead,
> JBoss Security & Identity Management
> JBoss, A division of Red Hat Inc.
> http://labs.jboss.com/portal/jbosssecurity/
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
Julien Viet
JBoss Portal Project Lead
Red Hat Inc.
http://jbossportal.blogspot.com/
Red Hat France SARL, 171 Avenue Georges Clemenceau, 92024 Nanterre
Cedex, France.
Siret n° 421 199 464 00056
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
9:36 p.m.
+1, we need to minimize logging dependencies.
On Thu, 2007-07-05 at 11:25 -0700, Scott M Stark wrote:
No, as I was loathe to introduce yet another logging wrapper.
Steve Ebersole wrote:
> On Thursday 05 July 2007 08:08:02 am Steve Ebersole wrote:
>> I am considering moving Hibernate to use slf4j instead of commons-logging.
>> I had been considering moving to straight log4j usage anyway to get MDC/NDC
>> capability, but slf4j just added this capability. So it now has all the
>> capabilities I need.
>>
>> Just curious whether anyone has seen it used within JBoss AS and what the
>> experiences were.
>
> So then back to my original question... ;)
>
> I guess noone has any compliants (or no experiences) with slf4j?
> _______________________________________________
> 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:51 p.m.
JBoss AS does not get to decide this for all the projects it uses, nor all the
libraries which conceivably will run in it. Obviously, if it is deemed that
important JBoss AS could choose to not use a library because it uses one
logging framework or another.
I don't know why everyone feels the need to answer questions I am not asking,
and not answer the ones I am :)
On Thursday 05 July 2007 02:36:10 pm Jason T. Greene wrote:
+1, we need to minimize logging dependencies.
10:48 p.m.
Integration as a whole is much easier if everyone tries to utilize the
work already done for common problems such as logging. If a feature is
missing from what we have then we need to enhance it, not pull in yet
another library.
On Thu, 2007-07-05 at 14:51 -0500, Steve Ebersole wrote:
JBoss AS does not get to decide this for all the projects it uses,
nor all the
libraries which conceivably will run in it. Obviously, if it is deemed that
important JBoss AS could choose to not use a library because it uses one
logging framework or another.
I don't know why everyone feels the need to answer questions I am not asking,
and not answer the ones I am :)
On Thursday 05 July 2007 02:36:10 pm Jason T. Greene wrote:
> +1, we need to minimize logging dependencies.
>
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
5:07 a.m.
On Thursday 05 July 2007 03:48:14 pm Jason T. Greene wrote:
Integration as a whole is much easier if everyone tries to utilize
the
work already done for common problems such as logging. If a feature is
missing from what we have then we need to enhance it, not pull in yet
another library.
So you're saying JBoss AS should force every library that gets used within it
to use the same logging APIs? Sorry, this is completely not the right
approach for what I thought should be obvious reasons...
5:18 a.m.
On Thursday 05 July 2007 01:25:17 pm Scott M Stark wrote:
No, as I was loathe to introduce yet another logging wrapper.
My concern with the org.jboss.logging.Logger stuff is specifically the lack of
MDC/NDC style capability.
Basically it comes down to the fact that I want to migrate Hibernate away from
commons-logging for numerous reasons (the classloader leaking stuff being
primary). Given that fact, I want the API to which I move to support MDC
(NDC is generally more useful for what I want to do but could be spoofed with
MDC). That means I can move to log4j, slf4j, or logback. Out of those,
slf4j seemed the most reasonable in terms of allowing easy integration with
various environemtns.
10:23 a.m.
On 7/6/07, Steve Ebersole <steve(a)hibernate.org> wrote:
On Thursday 05 July 2007 01:25:17 pm Scott M Stark wrote:
> No, as I was loathe to introduce yet another logging wrapper.
My concern with the org.jboss.logging.Logger stuff is specifically the lack of
MDC/NDC style capability.
Basically it comes down to the fact that I want to migrate Hibernate away from
commons-logging for numerous reasons (the classloader leaking stuff being
primary). Given that fact, I want the API to which I move to support MDC
(NDC is generally more useful for what I want to do but could be spoofed with
MDC). That means I can move to log4j, slf4j, or logback. Out of those,
slf4j seemed the most reasonable in terms of allowing easy integration with
various environemtns.
As I said a couple messages above, java.util.logging is more robust,
and allows formatters which could use thread local variables (I find
this habit of using hypish names to refer to simple pre-existing
things to be very annoying).
You don't really seem to be interested in our opinion overall, and
seem to be willing to use slf4j anyway, so I'm not sure what's the
point of posting here.
Rémy
11:42 a.m.
> MDC). That means I can move to log4j, slf4j, or logback. Out of
those,
> slf4j seemed the most reasonable in terms of allowing easy integration
> with
> various environemtns.
As I said a couple messages above, java.util.logging is more robust,
and allows formatters which could use thread local variables (I find
this habit of using hypish names to refer to simple pre-existing
things to be very annoying).
You don't really seem to be interested in our opinion overall, and
seem to be willing to use slf4j anyway, so I'm not sure what's the
point of posting here.
Rémy
Eh - Steve very clearly explained why jul is is not an option; it does
not have NDC/MDC.
And if you mean the "robust"'nes is just about "it's always
available
because it's in the jdk" - then why don't we purely use the jdk's
reflection api ? jdk's xml apis ? jdk's dateformatters ?
I can tell you why - because
1) it does not have the feature we need/want
2) it has bugs, and we can't fix bugs in it (in a timely manner)
3) it's not as efficient
so back to the question which still haven't been answered:
Anyone knows of any issue with slf4j with respect to integration ?
As we see it, it will/should work fine. Let us know if you know
of any known integration issues.
Thanks,
/max
6:55 p.m.
On Fri, 2007-07-06 at 11:42 +0200, Max Rydahl Andersen wrote:
>> MDC). That means I can move to log4j, slf4j, or logback.
Out of those,
>> slf4j seemed the most reasonable in terms of allowing easy integration
>> with
>> various environemtns.
>
> As I said a couple messages above, java.util.logging is more robust,
> and allows formatters which could use thread local variables (I find
> this habit of using hypish names to refer to simple pre-existing
> things to be very annoying).
>
> You don't really seem to be interested in our opinion overall, and
> seem to be willing to use slf4j anyway, so I'm not sure what's the
> point of posting here.
>
> Rémy
Eh - Steve very clearly explained why jul is is not an option; it does
not have NDC/MDC.
As Remmy said, this is easy to implement (it just a fancy name for using
a thread local). Also, I just looked at sl4j's source, and it relies on
the logging backend to actually implement MDC and NDC, so if you use
it's JUL backend it doesn't work!!
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
6:58 p.m.
On Friday 06 July 2007 11:55:52 am Jason T. Greene wrote:
On Fri, 2007-07-06 at 11:42 +0200, Max Rydahl Andersen wrote:
> >> MDC). That means I can move to log4j, slf4j, or logback. Out of
> >> those, slf4j seemed the most reasonable in terms of allowing easy
> >> integration with
> >> various environemtns.
> >
> > As I said a couple messages above, java.util.logging is more robust,
> > and allows formatters which could use thread local variables (I find
> > this habit of using hypish names to refer to simple pre-existing
> > things to be very annoying).
> >
> > You don't really seem to be interested in our opinion overall, and
> > seem to be willing to use slf4j anyway, so I'm not sure what's the
> > point of posting here.
> >
> > Rémy
>
> Eh - Steve very clearly explained why jul is is not an option; it does
> not have NDC/MDC.
As Remmy said, this is easy to implement (it just a fancy name for using
a thread local). Also, I just looked at sl4j's source, and it relies on
the logging backend to actually implement MDC and NDC, so if you use
it's JUL backend it doesn't work!!
Of course!
But why should I care. I don't want to write logging frameworks. I can't
think of anything more f'n boring.
7:28 p.m.
On Fri, 2007-07-06 at 11:58 -0500, Steve Ebersole wrote:
Of course!
But why should I care. I don't want to write logging frameworks. I can't
think of anything more f'n boring.
I will find some time to add it to jboss logging, including support for
log4j and jul:
http://jira.jboss.com/jira/browse/JBCOMMON-28
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
7:32 p.m.
I feel a "here we go again", coming on... ;)
Ok, has anyone used jboss common-logging outside of the app server?
Experiences? Remy: yes, yes, we understand your preference for JUL...
On Friday 06 July 2007 12:28:17 pm Jason T. Greene wrote:
On Fri, 2007-07-06 at 11:58 -0500, Steve Ebersole wrote:
> Of course!
>
> But why should I care. I don't want to write logging frameworks. I
> can't think of anything more f'n boring.
I will find some time to add it to jboss logging, including support for
log4j and jul:
http://jira.jboss.com/jira/browse/JBCOMMON-28
10:49 a.m.
Steve, no worries, you are not crazy or missing something: from the
outside this discussion is very funny as all people that replied to this
thread made sure to not even start answering your original question.
At this point, I think we can call this a form of art.
:)
Steve Ebersole wrote:
I feel a "here we go again", coming on... ;)
Ok, has anyone used jboss common-logging outside of the app server?
Experiences? Remy: yes, yes, we understand your preference for JUL...
On Friday 06 July 2007 12:28:17 pm Jason T. Greene wrote:
> On Fri, 2007-07-06 at 11:58 -0500, Steve Ebersole wrote:
>> Of course!
>>
>> But why should I care. I don't want to write logging frameworks. I
>> can't think of anything more f'n boring.
> I will find some time to add it to jboss logging, including support for
> log4j and jul:
> http://jira.jboss.com/jira/browse/JBCOMMON-28
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
10:34 p.m.
On Monday 09 July 2007 03:49:55 am Sacha Labourey wrote:
Steve, no worries, you are not crazy or missing something: from the
outside this discussion is very funny as all people that replied to this
thread made sure to not even start answering your original question.
At this point, I think we can call this a form of art.
:)
Steve Ebersole wrote:
> I feel a "here we go again", coming on... ;)
>
> Ok, has anyone used jboss common-logging outside of the app server?
> Experiences? Remy: yes, yes, we understand your preference for JUL...
>
> On Friday 06 July 2007 12:28:17 pm Jason T. Greene wrote:
>> On Fri, 2007-07-06 at 11:58 -0500, Steve Ebersole wrote:
>>> Of course!
>>>
>>> But why should I care. I don't want to write logging frameworks. I
>>> can't think of anything more f'n boring.
>>
>> I will find some time to add it to jboss logging, including support for
>> log4j and jul:
>> http://jira.jboss.com/jira/browse/JBCOMMON-28
>
> _______________________________________________
> 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
We have such an art form in the US at least. We call it politicing ;)
12:56 a.m.
On Fri, 2007-07-06 at 12:28 -0500, Jason T. Greene wrote:
On Fri, 2007-07-06 at 11:58 -0500, Steve Ebersole wrote:
> Of course!
>
> But why should I care. I don't want to write logging frameworks. I can't
> think of anything more f'n boring.
I will find some time to add it to jboss logging, including support for
log4j and jul:
http://jira.jboss.com/jira/browse/JBCOMMON-28
I finally got around to this. Full support of NDC and MDC is now in
jboss-common-logging 2.0.5-SNAPSHOT. The API is very close to the log4j
version, but with some small simplifications. This functionality can be
used with both log4j and JUL backends. The JUL backend requires the
JBoss log manager to be loaded:
-Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.jdk.JDK14LoggerPlugin
-Djava.util.logging.manager=org.jboss.logging.jdk.JDKLogManager
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
2:34 a.m.
On 7/10/07, Jason T. Greene <jason.greene(a)redhat.com> wrote:
I finally got around to this. Full support of NDC and MDC is now in
jboss-common-logging 2.0.5-SNAPSHOT. The API is very close to the log4j
version, but with some small simplifications. This functionality can be
used with both log4j and JUL backends. The JUL backend requires the
JBoss log manager to be loaded:
-Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.jdk.JDK14LoggerPlugin
-Djava.util.logging.manager=org.jboss.logging.jdk.JDKLogManager
I think I'm going to adopt this branch of jboss-common-logging in
JBoss Web 2.1 (replacing a package renamed commons-logging), and if
you don't mind I'll also pick up your changes to the JUL log manager
in the Tomcat JUL log manager.
Rémy
9:14 a.m.
If this is to go to AS 4.2.x, too, just make sure we get the dependencies right, because
it
uses jboss commons 1.2, I think.
Rémy Maucherat wrote:
On 7/10/07, Jason T. Greene <jason.greene(a)redhat.com> wrote:
> I finally got around to this. Full support of NDC and MDC is now in
> jboss-common-logging 2.0.5-SNAPSHOT. The API is very close to the log4j
> version, but with some small simplifications. This functionality can be
> used with both log4j and JUL backends. The JUL backend requires the
> JBoss log manager to be loaded:
>
> -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.jdk.JDK14LoggerPlugin
> -Djava.util.logging.manager=org.jboss.logging.jdk.JDKLogManager
>
I think I'm going to adopt this branch of jboss-common-logging in
JBoss Web 2.1 (replacing a package renamed commons-logging), and if
you don't mind I'll also pick up your changes to the JUL log manager
in the Tomcat JUL log manager.
Rémy
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
3:01 p.m.
Rémy Maucherat wrote:
On 7/10/07, Jason T. Greene <jason.greene(a)redhat.com> wrote:
> I finally got around to this. Full support of NDC and MDC is now in
> jboss-common-logging 2.0.5-SNAPSHOT. The API is very close to the log4j
> version, but with some small simplifications. This functionality can be
> used with both log4j and JUL backends. The JUL backend requires the
> JBoss log manager to be loaded:
>
> -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.jdk.JDK14LoggerPlugin
> -Djava.util.logging.manager=org.jboss.logging.jdk.JDKLogManager
>
I think I'm going to adopt this branch of jboss-common-logging in
JBoss Web 2.1 (replacing a package renamed commons-logging), and if
you don't mind I'll also pick up your changes to the JUL log manager
in the Tomcat JUL log manager.
Sure, let me know if you run into any problems.
-Jason
1:44 p.m.
I asked a question, and folks (especially you) seem more intent on answering
some other unasked question. So not sure whats the point of your continued
replies. But thanks anyway.
JUL is not an option for reasons which I already stated a couple of messages
above. Plus the fact that noone in java (except you apparently) uses JUL nor
even knows how to configure it or set it up. But thanks anyway.
I find this line of reply annoying. But thanks anyway.
On Friday 06 July 2007 03:23:32 am Rémy Maucherat wrote:
On 7/6/07, Steve Ebersole <steve(a)hibernate.org> wrote:
> On Thursday 05 July 2007 01:25:17 pm Scott M Stark wrote:
> > No, as I was loathe to introduce yet another logging wrapper.
>
> My concern with the org.jboss.logging.Logger stuff is specifically the
> lack of MDC/NDC style capability.
>
> Basically it comes down to the fact that I want to migrate Hibernate away
> from commons-logging for numerous reasons (the classloader leaking stuff
> being primary). Given that fact, I want the API to which I move to
> support MDC (NDC is generally more useful for what I want to do but could
> be spoofed with MDC). That means I can move to log4j, slf4j, or logback.
> Out of those, slf4j seemed the most reasonable in terms of allowing easy
> integration with various environemtns.
As I said a couple messages above, java.util.logging is more robust,
and allows formatters which could use thread local variables (I find
this habit of using hypish names to refer to simple pre-existing
things to be very annoying).
You don't really seem to be interested in our opinion overall, and
seem to be willing to use slf4j anyway, so I'm not sure what's the
point of posting here.
Rémy
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
6:51 p.m.
On Thu, 2007-07-05 at 22:18 -0500, Steve Ebersole wrote:
On Thursday 05 July 2007 01:25:17 pm Scott M Stark wrote:
> No, as I was loathe to introduce yet another logging wrapper.
My concern with the org.jboss.logging.Logger stuff is specifically the lack of
MDC/NDC style capability.
This can easily be added, its just a thread local.
--
Jason T. Greene
Lead, POJO Cache
JBoss, a division of Red Hat
6132
days inactive
6148
days old
jboss-development@lists.jboss.org
31 comments
10 participants
participants (10)
-
Adrian -
Anil Saldhana -
Dimitris Andreadis -
Jason T. Greene -
Julien Viet -
Max Rydahl Andersen -
Rémy Maucherat -
Sacha Labourey -
Scott M Stark -
Steve Ebersole