Yes, one of the things I've been doing... I've got the changes in my
workspace and am testing now.
Marina Vatkina wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>