On 06/06/2012 02:17 PM, Bill Burke wrote:
On 6/6/12 2:41 PM, David M. Lloyd wrote:
> 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. :)
>
"easy to use" is certainly your perception, not mine.
And my logger is not a full-blown abstraction, just a small wrapper over
existing logging frameworks. But...since you couldn't provide simple
methods like:
String getMessage(long messageId, Object... params);
info(long messageId, Object... params)
I'm stuck writing Yet Another Redundant Fucking Logging Abstraction for
i18n because I absolutely refuse to be dependent on any specific Yet
Another Fucking Logging Abstraction.
Up to you, but you get to be the one to tell the translation team why
they have to key all their messages off of an integer ID instead of a
descriptive name. And you also get to reinvent the tooling which
provides them with the English translation to work from. Doesn't sound
like a good use of time to me.
--
- DML