[jboss-as7-dev] manual way to do logging?

[David M. Lloyd]

On 06/06/2012 05:32 PM, Bill Burke wrote:
>
>
> 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.
>
>>> 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...

I don't see the problem with it.  It's lightweight and it works, and 
it's fast.  Using it is super easy, just annotate an interface.  Your 
objection is that it generates classes?  So what if it does?  There's no 
cost to the developer or the user.  You just add a compile time dep and 
you're done.

I don't get what the advantage to this is:

> void info(String messageID, Object... params);
> void trace(String messageID, Object... params);
> void error(String messageID, Object... params);

It's more error prone, uses more memory and doesn't really help you when 
you're constructing or logging exceptions (which also need IDs).

> 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.

But what's the advantage?  That is what I don't understand.  Our tooling 
basically costs you almost nothing (just a compile-time dep) and uses 
very little memory at runtime.  It does the job well.

> 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.

I assume you mean @org.jboss.logging.MessageBundle?  If so, of course 
it's fine to use, that's why we put it in there.  The annotations all 
have source retention though, so reflection will avail you nothing.  In 
any case, using message bundle-style messages with an abstraction over 
our standard abstraction instead of just using log methods is nothing 
but spite; it's truly silly.

So basically I think you're mad because you invested in a log 
abstraction framework for your project and now it's turning out to have 
been a mistake, which anyone could have told you was going to happen. 
No other explanation makes any kind of sense for this level of objection 
to what's basically a minimal, clean tool.

JBoss-logging *is* the abstraction.  Making another abstraction over it 
is just silly, especially when it does all the work for you and you have 
so many options for using it, including an option whereby you can easily 
pull in and relocate the classes (and thus not even have a user-visible 
dependency).

> I don't want to be
> dependent on yet another logging abstraction and questioned why we were
> spending so many engineering hours on one.

I don't think all that many engineering hours were spent on it. 
Certainly fewer than the combination of everyone who has added their own 
logging abstraction to their projects.  Ending that silliness is worth 
the investment I think.  I for one am very glad to not have to worry 
about it anymore.

-- 
- DML