On 06/06/2012 01: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.
Yes, creating your own abstraction when there's a perfectly good one
ready and easy to use is indeed over-engineering. :)
All jboss-logging is, is an API (a pretty damn good one if I may say so)
on a Logger class plus automatic backend detection. That's about as
close to the ideal of a minimal, most efficient/effective solution to a
problem as is humanly achievable if you ask me. Shading in the
dozen-odd logging classes from a tried and true framework (which btw we
are all basically required to use to accommodate i18n anyway) seems a
lot less over-engineered than creating Yet Another Redundant Fucking
Logging Abstraction which will *no doubt* make all the same mistakes
that all the others have made.
--
- DML