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

[Thomas Diesler]

Out of curiosity: when you're done with actually meeting the TAG 
requirements please let us know how much effort it was to create that 
abstraction and what the benefits actually are. Perhaps you're right and 
it is worth for every project to create its own logging abstraction. 
Unless I see proof to the contrary - I doubt that ;-)

On 06/22/2012 01:12 PM, Bill Burke wrote:
> You are really gonna bring this up again?  I spent 10 minutes on my 
> logging abstraction about 3 years ago, and will spend 2 more minutes 
> hooking in resource bundle support and have zero code/library 
> dependencies and avoid the performance hit that jboss-logging 
> currently has (well, the code generation part of it anyways) and have 
> something thats 100 times simpler that uses traditional best practices 
> and libraries.  So I guess you should rephrase your response...
>
> On 6/22/12 6:50 AM, Thomas Diesler wrote:
>> You may find that you need to spend so much energy on your logging
>> abstraction that it makes you wonder why not to use jboss-logging as
>> your logging abstraction in the first place. Is this NIH?
>>
>> -thomas
>>
>> On 06/06/2012 08:32 PM, Bill Burke wrote:
>>>
>>> On 6/6/12 2:11 PM, David M. Lloyd wrote:
>>>> On 06/06/2012 12:35 PM, Bill Burke wrote:
>>>>> I do not want to use the JBoss Logging annotation framework as I 
>>>>> do not
>>>>> want to have a hard dependency on JBoss Logging for my project.
>>>>>
>>>>> Is there a manual API that I can use instead to build a message?
>>>>> Something like:
>>>>>
>>>>> String getMessage(long id, Object... params);
>>>> No, there isn't (and if there were, it'd be part of JBoss Logging,
>>>> so...). You can however use the maven-shade-plugin to slurp the JBoss
>>>> Logging classes into your project (even under another package name).
>>>> It's a pretty small project and we're working to make it smaller.
>>>>
>>> Eh, I guess I could just use reflection techniques to create my own
>>> abstraction and stuff the logging interfaces in a separate jar.
>>>
>>> BTW, this is ridiculously over-engineered and at least for me, 
>>> harder to
>>> adapt to my project.  These engineering hours could have been better
>>> spent elsewhere.
>>>
>>
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx