Right. Another thing -- developers should maintain LogStrings.properties (case
sensitive, right?)
Also, I think the "names" of the loggers are of essence here. From that point
of view, Logger.getLogger(String name) is appropriate if you know the name
of the logger you use and don't want to have a dependency on LogDomains.
Is that a correct?
Going ahead, I think we should expose the names of the loggers via tools and
configuration. This was rather coarse grained in V2. In V2, we also had the
names of the loggers exposed as property in log-service.
Another tip is: if you change the string INFO from your domain-folder/config/
logging.properties to FINE, you'll see all the loggers to log FINE and above
level records.
Carla -- can you please modify the default logging.properties (yes,
logging.properties, not LogStrings.properties) with the names of some of our
loggers (e.g. WEB, ADMIN, ROOT etc.) so that people can get used to their names?
This will also help users know which subsystem in v3 Prelude uses which logger.
This is all the more important since we have no tool support in Prelude.
Thanks,
Kedar
Marina Vatkina wrote:
> Jerome,
>
> We are passing in a class, not a class loader to LogDomains.getLogger() :).
>
> thanks,
> -marina
>
> Jerome Dochez wrote:
>> Hi All
>>
>> Following the conversation we had during the dev meeting today. The
>> easiest way to ensure proper loading of your logStrings.properties
>> file depends on the following conditions :
>>
>> First remember that loggers in GlassFish are organized per functional
>> area so you have a unique Web, and EJB, an admin logger instance.
>>
>> 1. only one bundle uses the logger instance :
>> 1.1 place the resource inside that bundle, at the top of your
>> hierarchy or work with Carla on the full path you should use for your
>> file.
>> 1.2 use LogDomains.getLogger(this.getClass().getClassLoader(),
>> LogDomains.Web) to access your instance.
>>
>> 2. mulitple bundles use the same logger instance :
>> - place the resource in the common bundle (the one imported by all
>> the others, you usually have that, worse case, put it in common-util,
>> it's imported by everyone.
>> - do either one of the 2 actions :
>> 2.1 Rely on OSGi import/export
>> For example, you want to share a
>> com.sun.logging.enterprise.system.container.web.LogStrings.properties, do
>> 2.1.1. export the package from the bundle containing the
>> resource
>>
>> -exportcontents: \
>> com.sun.enterprise.glassfish.web, \
>> +
>> com.sun.logging.enterprise.system.container.web, \
>>
>> 2.1.2 import that package in all bundles sharing the logger
>>
>> Import-Package: \
>> +
>> com.sun.logging.enterprise.system.container.web, \
>> 2.1.3 use
>> LogDomains.getLogger(this.getClass().getClassLoader(), LogDomains.WEB);
>>
>>
>> 2.2 Rely on BND to do the package import/export by using a class
>> dependency
>>
>> 2.2.1 Say that your common bundle that has the resource also has a
>> class called org.glassfish.util.Random, you can just do
>> Logger logger =
>> LogDomains.getLogger(org.glassfish.util.Random.class, LogDomains.WEB);
>>
>> as you can see 2.2 is the easiest when dealing with multiple bundles
>> sharing a Logger and therefore a resource bundle. The key is to give
>> to the LogDomains.getLogger API a instance of type Class which
>> classloader's can be used to load the associated resource bundle.
>>
>> Jerome
>>
>> ---------------------------------------------------------------------
>> 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
>