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
>