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*)?
When the new API will be available?
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
>