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
>