HI Lloyd,
Sorry for all the emails and confusion. Things have settled down now.
Yes you can and should put the LogStrings.properties file into the
package that uses it. The issue that arose yesterday was that in some
modules there are several packages which share one copy of the
LogStrings.properties file. In order for that to work the osgi.bundle
file in the package that contains LogStrings.properties needs to export
that package *and* the package that uses it must have an import-package
statement in it's osgi.bundle file. This is what I could not clearly
explain yesterday.
Another solution would be to split up the LogStrings.properties file
such that each package contains one with the messages that apply to that
package.
Hope this makes sense.
Carla
Lloyd Chambers wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>