10:28 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Jason T. Greene" <jason.greene(a)redhat.com>
Cc: "Andrig Miller" <anmiller(a)redhat.com>, "JBoss AS7
Development" <jboss-as7-dev(a)lists.jboss.org>
Sent: Wednesday, June 6, 2012 4:32:02 PM
Subject: Re: [jboss-as7-dev] manual way to do logging?
On 6/6/12 5:02 PM, Jason T. Greene wrote:
> On 6/6/12 3:43 PM, Andrig Miller wrote:
>
>> I'm not sure we have to have these discussions over and over and
>> over
>> again. From my perspective, performance being my primary concern,
>> JBoss logging has been awesome, and it meets all the companies
>> requirements. I haven't been able to put an exact percentage on it
>> yet, but the use of JBoss logging has improved throughput on all
>> the
>> workloads I have tested, that is for sure.
>>
The performance gains you are seeing are from not doing stupid things
which are pretty easy to avoid. i.e. not doing string concatenations
when your logging level isn't triggered.
That's only part of it. The design overall is much better from a performance
perspective too. You can still use it poorly and have performance issues, as with
anything.
>> If we continue to pollute the code base with different
logging
>> frameworks, a lot of those gains could start to disappear. Besides
>> the fact, that we are about to ship a product in multiple
>> languages
>> for the first time, and we have to continue to finish the work we
>> started.
>>
>> Is is all that difficult to adopt JBoss logging? This all seems
>> counter productive.
>
> Right I think we need to know why it needs to be abstracted. What
> is
> missing from jboss logging that requires RESTEasy to have an
> abstraction? Once we know the answer to that question, we can
> either add
> whatever the missing thing is, or recommend how to go about
> building
> something custom with similar perf characteristics (if the advice
> is
> even wanted).
>
The reasons are simple: I don't want a *hard* dependency on yet
another
logging abstraction within my codebase. I really don't want to write
a
logging abstraction, I just want to have a tiny level of indirection
so
that I'm not dependent on any one of them. You don't think I have
any
right to be a little frustrated that I can't do this tiny level of
indirection and that I have to use a full-blown code generation
framework just to do logging? You don't think it is even a little
bit
ridiculous that you are requiring code generation just to do logging?
Come on guys...
You asked what's missing from JBoss Logging, I'll reiterate more
completely:
void info(String messageID, Object... params);
void trace(String messageID, Object... params);
void error(String messageID, Object... params);
String getMessage(String messageID, Object... params);
MessageFormat getMessageFormat(String messageID);
Simple as that. You can whine about the performance implications all
you want but, IMO, if you do a log-level check before you lookup the
message, it shouldn't be an issue.
BTW, nobody answered my previous question, @MessageBundle is fine to
use? Our translation teams know how to handle them? Considering you
think JBoss Logging is already perfect, I'm guessing I'll have to
revert
to using reflection calls on @MessageBundle if I want to keep my
delegation logger.
P.S. BTW Jason, I did comment multiple times on TAG-3 years ago. I'd
be
happy to forward the emails. What I said then was: I don't want to
be
dependent on yet another logging abstraction and questioned why we
were
spending so many engineering hours on one.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
I'm not sure why you don't want a hard dependency on the logging framework, and
why that is so important. As I see it, the only way RestEasy makes any money for us is in
EAP, so what's the big deal about having a hard dependency on jboss logging? Is it
that you vision RestEasy to be used in other containers too? If so, is it happening in
the community? It certainly won't happen with paying customers.
Andy