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
>