Yes. I did it in transaction submodules yesterday.
-marina
Lloyd Chambers wrote:
> This is all confusing. I came back today, and there were 32 messages on
> this.
>
> The only think that make intuitive sense to me is to have a
> LogStrings.properties file in the same package (or close parent
> package) of the code that uses it.
>
> So I'm not sure I understand. If I have package
> com.sun.appserv.management, can I put LogStrings.properties into that
> package or not?
>
> Lloyd
>
> ..............................................
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish team, LSARC member
>
> On Sep 10, 2008, at 1:58 PM, Marina Vatkina wrote:
>
>> No, I mean the location of the LogStrings.properties bundle.
>>
>> You said that allowing the resource bundle to be in any other package
>> (i.e. location) than the package it existed in common-util (i.e.
>> before your change), will cause class loading problems.
>>
>> Is it the case?
>>
>> If yes, why is it so?
>>
>> If not, what prevents us from having LogStrings.properties in the
>> same package as the class that requested the logger (or its parent
>> package) as described in Jerome in his original email?
>>
>> 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>