Carla, Jerome,
Will you modify existing calls to LogDomains.getLogger() as part of this change?
We (other modules) won't have time to do it before HCF otherwise.
thanks,
-marina
Carla Mott wrote:
>
> The new code is looking for LogStrings.properties
>
> I'm trying to get this done by end of this week.
>
> carla
>
>
> Marina Vatkina wrote:
>
>> Jerome Dochez wrote:
>>
>>> Marina Vatkina wrote:
>>>
>>>> Jerome,
>>>>
>>>> In v2 (and currently under common/common-util) those resource
>>>> bundles are called LogStrings.properties. Do you propose to merge
>>>> their content with the existing LocalStrings.properties (and it's
>>>> plural - LocalString*s*)?
>>>>
>>> no if you start having local LocalStrings.properties file then you
>>> should move all of the strings from common/common-util
>>
>>
>> No to merge the 2 into 1, or no to rename LogStrings.properties to
>> LocalStrings.properties?
>>
>> Will the new code look for LogStrings.properties or
>> LocalStrings.properties?
>>
>> thanks,
>> -marina
>>
>>>
>>>> When the new API will be available?
>>>
>>>
>>> carla would need to comment here.
>>>
>>>>
>>>> thanks,
>>>> -marina
>>>>
>>>>
>>>> Jerome Dochez wrote:
>>>>
>>>>> As discussed in the engineering meeting, I am proposing to change
>>>>> the API we use to access the logger API.
>>>>>
>>>>> In v2, and up to now in V3, we we using the following API from
>>>>> LogDomains.java :
>>>>> Logger getLogger(String loggerName);
>>>>>
>>>>> the loggerName was used to both segregate which logger instance
>>>>> (with a particular log level setting) you requested but was also
>>>>> defining the name of the LocalString.properties file in which the
>>>>> strings would be located.
>>>>>
>>>>> I am proposing we change the API to
>>>>> Logger getLogger(Class requesterClass, String loggerName);
>>>>>
>>>>> The role of the Class parameter is to obtainer a class loader doing
>>>>> requesterClass.getClassLoader() which will be responsible for
>>>>> finding the resource bundle. The name will just be used to identify
>>>>> which logger instance you request.
>>>>>
>>>>> 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
>>>>> 3. for backward compatibility with existing code, we will use
>>>>> the obtained class loader to load the old resource bundle using the
>>>>> mapping we had in v2 (this lookup will gradually fail more and more
>>>>> as people move their resource bundle in their package).
>>>>> 4 throw a MissingResourceBundleException.
>>>>>
>>>>> It does mean that if you start using a LocalStrings file in your
>>>>> module's packages, we will not load the resources from the previous
>>>>> resource bundle as in v2 and you need to move these resources in
>>>>> your module.
>>>>>
>>>>> I believe that most people do not have to do any of this right now,
>>>>> as we can rely on step (3) to load the resources successfully. For
>>>>> instance, if you module imports the package containing the resource
>>>>> bundle from another bundle, then OSGi should give you access to it.
>>>>> But we should move these resources after prelude. If you have any
>>>>> issues preventing you from loading these resources, please move
>>>>> them now.
>>>>>
>>>>> Let me know if you have any questions/concerns.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>