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
> 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
>