Don't worry. Your code works correctly. It was a problem in my pom.xml that
didn't pick up the moved resource bundle.
Again, sorry for the confusion.
Regards,
-marina
Carla Mott wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>