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
>