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
>