<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
On 06/06/2012 03:32 PM, Bill Burke wrote:
<blockquote cite="mid:4FCFDA62.7050100@redhat.com" type="cite">
<pre wrap="">
On 6/6/12 5:02 PM, Jason T. Greene wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 6/6/12 3:43 PM, Andrig Miller wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
<pre wrap="">
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...</pre>
</blockquote>
You've essentially written what's already done just more completely
in JBoss Logging<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://github.com/resteasy/Resteasy/tree/master/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/logging">https://github.com/resteasy/Resteasy/tree/master/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/logging</a><br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://github.com/jboss-logging/jboss-logging/tree/master/src/main/java/org/jboss/logging">https://github.com/jboss-logging/jboss-logging/tree/master/src/main/java/org/jboss/logging</a><br>
<br>
Yes there are more classes, 10 of which are just annotations, but
they're not all the different from what you've already done. Think
of it as a positive, now you don't have to maintain logging bridges
:-)<br>
<blockquote cite="mid:4FCFDA62.7050100@redhat.com" type="cite">
<pre wrap="">
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);</pre>
</blockquote>
I just can't see what this adds except a greater possibility of
runtime errors. No validation can be done on the parameters you're
passing to the message. If the ID doesn't exist, then what? Throw an
exception that now you have add try/catches around and decide how to
safely fail.
<blockquote cite="mid:4FCFDA62.7050100@redhat.com" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
No the translation team needs properties files. The logging tooling
generates the properties files for you by default.<br>
<blockquote cite="mid:4FCFDA62.7050100@redhat.com" type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<blockquote cite="mid:4FCFDA62.7050100@redhat.com" type="cite">
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
James R. Perkins
JBoss by Red Hat</pre>
</body>
</html>