Are the logger names the same names used in the module-log-levels
element in previous releases, or are they different? Please say they
are the same!
June
On 09/17/08 14:56, Kedar Mhaswade wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>