Carla,
In your own commit message, you listed these points from Jerome's email (and it
still says LocalString.properties):
---------------
the resource bundle will be looked using the following algorithm
1. we will get the Package name from the passed requesterClass and lookup
the resource bundle in that package using the following name :
requesterClass.getPackage().getName + ".LocalString.properties" and
the current Locale of course.
2. we will walk up the package hierarchy and repeat (2) until we get to the root
---------------
Is it implemented that way or is it not?
thanks,
-marina
Carla Mott wrote:
> Are you questioning why com.sun.logging is preappended to the name of
> the logger? If so, I have no idea. That is how the code was written
> and I didn't change it.
>
> CArla
>
> Marina Vatkina wrote:
>
>> I'm still confused...
>>
>> How is it different to load com/sun/logging/xyz/LogStrings.properties
>> vs. com/sun/foo/bar/LogStrings.properties if they are in the same OSGi
>> bundle?
>>
>> thanks,
>> -marina
>>
>> Carla Mott wrote:
>>
>>>
>>>
>>> Before any investigation he thought that it would be trivial to do
>>> just that. Once I made the code change we discovered that in fact
>>> (b) would required changes to all the modules' pom.xml file. At that
>>> point the choice was to either make that change or move the resource
>>> bundles. Apparently the long term solution (the way things should be
>>> in v3 final) is to move the resource bundles so that is the route I
>>> took based on Jerome's request. I don't know when the long term
>>> solution was decided on or where it was discussed, again I don't have
>>> the history. Maybe Jerome can provide more info.
>>>
>>> Carla
>>>
>>> Marina Vatkina wrote:
>>>
>>>> Carla,
>>>>
>>>> I'm confused...
>>>>
>>>> Jerome said that:
>>>> a) it's ok (and even preferable) to move the resource bundles.
>>>> b) the code will change to support resource bundles in the package
>>>> of the caller (which is the way things usually are between the
>>>> caller and a resource bundle).
>>>>
>>>> What do you mean by "he decided that the resources should be moved
>>>> as that is the long term plan"?
>>>>
>>>> Does the new code support point b)? If not, when will this be
>>>> available? Do we have a bug filed if it's not yet available?
>>>>
>>>> There was no discussions on why the files are under common-util
>>>> (that was a pre-GF decision to have all logging messages together
>>>> for probably an easier translation).
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>>
>>>> Carla Mott wrote:
>>>>
>>>>> He did describe that in his email but when we discovered the
>>>>> changes needed for that he decided that the resources should be
>>>>> moved as that is the long term plan. Not sure why the files are
>>>>> where they are now.
>>>>>
>>>>> Unfortunately I don't have the history of how things are now but
>>>>> just the info of how things are supposed to work moving forward.
>>>>>
>>>>> Carla
>>>>>
>>>>> Marina Vatkina wrote:
>>>>>
>>>>>> Carla,
>>>>>>
>>>>>> Jerome described in his email that the new logger will use the
>>>>>> package name of the class passed to it, to find the resource
>>>>>> bundle (and as the last resource fall back to the old name).
>>>>>>
>>>>>> Did this rule change? (It'd be really strange to require for each
>>>>>> module to keep com/sun/logging package in it).
>>>>>>
>>>>>> thanks,
>>>>>> -marina
>>>>>>
>>>>>> Carla Mott wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm in the process of making changes to the logging code that
>>>>>>> supports the changes Jerome described in his previous email
>>>>>>> (subject Logger Changes). Note that the resource bundle
>>>>>>> filename is *LogStrings.properties* and not LocalStrings.properties.
>>>>>>>
>>>>>>> Once the logger changes are in you may be required to make
>>>>>>> additional changes to your module. Specifically you may need to
>>>>>>> move the LogStrings.properties file from its current location to
>>>>>>> the appropriate place. I did move the LogStrings.properites
>>>>>>> files that were causing the quicklook tests to fail but I didn't
>>>>>>> move all of them. It turns out that all the
>>>>>>> LogStrings.properties file are under common/common-util but in
>>>>>>> order for things to work correctly we had the choice of doing one
>>>>>>> of two things.
>>>>>>>
>>>>>>> 1. Leave the LogStrings.properties file where they were and
>>>>>>> update the osgi.bundle file to export them AND each pom.xml file
>>>>>>> to import the package where the resource properties files are.
>>>>>>> Temp solution.
>>>>>>>
>>>>>>> 2. Move the LogStrings.properties file to the module where they
>>>>>>> are used. This is the long term solution so we decided to go
>>>>>>> with this rather than update the pom.xml files and then move the
>>>>>>> files later.
>>>>>>>
>>>>>>>
>>>>>>> As I said I did move several of the files to the appropriate
>>>>>>> modules but there are others that need to be moved. I moved the
>>>>>>> following files:
>>>>>>>
>>>>>>> com/sun/logging/enterprise/system/tools/deployment/LogStrings.properties
>>>>>>>
>>>>>>> com/sun/logging/enterprise/system/core/security/LogStrings.properties
>>>>>>>
>>>>>>> com/sun/logging/enterprise/system/container/web/LogStrings.properties
>>>>>>>
>>>>>>> com/sun/logging/enterprise/resource/jta/LogStrings.properties
>>>>>>>
>>>>>>> When the logger doesn't find the resource bundle it will throw
>>>>>>> MissingResourceException. All resource bundles need to start
>>>>>>> with com.sun.logging which is the package name preappended to the
>>>>>>> Logger name found in LogDomains.java.
>>>>>>>
>>>>>>> Let me know if you have any questions.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Carla
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>