Good news: item #1 works: the log manager does find LogStrings.properties
correctly when it's placed in the calling class package.
Bad news: item #2 doesn't (is it the cause of #6053?): the log manager can't
find LogStrings.properties if it's in the parent package.
Regards,
-marina
Marina Vatkina wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>