Hi Dies
My example is indeed confusing since I use the string manager to load
the strings that is eventually displayed. However, there is still plenty
of code in glassfish (not mentioning existing logger code) that need to
have access to the string manager (as you mentioned), So my example was
not so much on how to use logger with string managers, but really how to
get a StringManager instance when you must have one.
do that make sense ?
On 7/22/10 6:11 PM, Koper, Dies (FAST) wrote:
> Hi Jerome,
>
> Your counter-proposal (or at least the client example) seems to go
> against the logging mechanism explained for GFv3.1 at the Logging wiki:
>
> http://wikis.sun.com/display/glassfish/GlassFishV3LoggingMessageFormat
>
> We should just pass message keys to logger.log(...) and let it handle
> the lookup of the messages. That way the code looks cleaner too.
>
> The problem with encouraging the developers to keep putting all their
> messages in LocalStrings.properties instead of using
> LogStrings.properties is that it makes the effort of creating diag
> messages and message ids so much harder.
>
> I think Byron's proposal is only target at exception messages (which
> don't use Logger) so there is no issue.
>
> Regards,
> Dies
>
>
>
>> -----Original Message-----
>> From: Jerome Dochez [mailto:jerome.dochez_at_oracle.com]
>> Sent: Wednesday, 21 July 2010 15:39
>> To: dev_at_glassfish.dev.java.net
>> Subject: Re: Local Strings in GlassFish
>>
>> On 7/20/10 2:55 PM, Byron Nevins wrote:
>>
>>> I have a proposal for a new convention for getting localized Strings
>>> at runtime. We've discussed this in Admin meetings and it was
>>>
> agreed
>
>>> that it is useful.
>>>
>>> Now I'm opening it up to the entire GlassFish community. Please
>>>
> take
>
>>> a look at this SHORT simple proposal [1]. All comments are welcome.
>>>
>>> [1] http://blogs.sun.com/foo/entry/local_strings_in_glassfish_a
>>>
>>>
>>>
>> I have a counter proposal :)
>>
>> Let's leverage injection to figure out which instance of StringManager
>> should be injected...
>>
>> For instance :
>>
>> @Service
>> @PerLookup
>> public class StringManager implements Injectable {
>>
>> StringManagerImpl delegate;
>>
>> public void injectedInto(Object target) {
>> delegate = StringManager.getManager(target.getClass());
>> }
>>
>> public String get(String label, Object... args) {
>> return delegate.get(label, args);
>> }
>> }
>>
>> Now in the client code ...
>>
>> @Service
>> public RandomCode implements RandomContract {
>>
>> @Inject
>> StringManager strMgr;
>>
>> public void someMethod(....) {
>>
>> logger.log(strMgr.get("mylabe", foo, bar));
>>
>> }
>> }
>>
>> The key to understand the code above is Injectable, check hk2
>>
> javadocs,
>
>> it means that the StringManager has a chance to know where it is being
>> injected into...
>>
>> Advantages : no extra code needed per package, no static field
>> whasoever
>> (YEAH !), every gets garbaged collected in the right time.
>> Disavantages : we have to change all StringManager pattern and it
>> requires DI (habitat lookup will not work here since Injectable
>> interface only works when injected).
>>
>> We should do the same thing with Logger.
>>
>> Jerome
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>