Thanks for trying this out so soon. I will look into why item #2 isn't
working.
Carla
Marina Vatkina wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>