On 6/7/12 3:19 PM, David M. Lloyd wrote:
On 06/07/2012 02:06 PM, Bill Burke wrote:
>
>
> On 6/6/12 7:09 PM, Jason Greene wrote:
>> On Jun 6, 2012, at 5:32 PM, Bill Burke<bburke(a)redhat.com> wrote:
>>>
>>> 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.
>>
>>
>> Sure you ignored everyone's use cases, everyone's research and findings
and then spent what 10 seconds of real thought to dump out some drivel about how everyone
is over engineering and wasting time?
>
> I think the reasons for my approach to logging are valid. I was wrong
> to assume 2 years ago that a simple old-school approach would be offered
> in parallel to the behemoth you created. Sucks that my dead-simple
> approach cannot be accommodated.
Calling it a "behemoth" doesn't make it one.
Let's see:
1. Write interface(s) with a method for each thing you want to log
(annotated of course).
2. Add a maven plugin to generate code in your project
3. add generated code to your project
4. add X classes to your project and the permgen space associated with them.
5. Create a hard dependency to JBoss Logging or yet another maven plugin
to shade in that dependency
vs.
log.info(ID, Object... args);
String msg = localization.generateMessage(ID, Object... args);
2 function calls compared to X extra Classes, Y extra methods, Z extra
annotations, one extra maven plugin, generated code, and an extra hard
library dependency unless you shade it in with an additional maven plugin.
To gain:
* in all probability, an array index instead of a hash lookup to locate
a message format.
* "Type safety". for an interface that has *ONLY ONE REFERENCE* and of
which type safety is meaningless considering all you're doing is
generating strings.
Yup, pretty much a behemoth.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com