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

Jason Greene jgreene at redhat.com
Wed Jun 6 18:48:48 EDT 2012



Sent from my iPhone

On Jun 6, 2012, at 5:32 PM, Bill Burke <bburke at redhat.com> 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.
> 

Not entirely. Even that is slow, the logging checks in abstractions and their integrations with the back end. Resource lookups are slow with i8ln. 


>>> 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.
 
You need only one and that's not answering the question. Why cant jboss logging be your one abstraction?


>  I really don't want to write a logging abstraction,

So use the one we wrote.


> I just want to have a tiny level of indirection so that I'm not dependent on any one of them.


Why? I don't understand why you can't offer a reason other than "I don't want it", which isn't a reason.

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

Nope. You need to actually do a little homework before ranting.


> You don't think it is even a little bit ridiculous that you are requiring code generation just to do logging? Come on guys...

Nope. It's the only way to not incur the cost of resource bundles and have the message in the java file and have a resource file the loc team can use.



> 
> You asked what's missing from JBoss Logging, I'll reiterate more completely

You are confusing implementation with requirements. You need to offer a valid use case.


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


Look if you don't answer my simple questions then I have nothing further to say.

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



More information about the jboss-as7-dev mailing list