Thanks Carla,
Is there an "official idiom" then for using LogStrings.properties?
(Eg utility or wrapper routines of any kind that we are converging on).
Lloyd
On Sep 11, 2008, at 1:31 PM, Carla Mott wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>