June.Parks_at_Sun.COM wrote:
> 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!
I wish I could say it. No, they are not. The attributes of log-service
elements were just identifiers of the functional area. The names of
the loggers are different. Unfortunately, the logging.properties
only understands the complete names of loggers. Thus, following
equivalence loosely holds for all log-service attributes:
domain.xml.log-service:"admin" ::
logging.properties:javax.enterprise.system.tools.admin
But you should not worry. We will have to do the mapping
as a backward compatibility exercise anyway, when we support
log-service from domain.xml going ahead after Prelude.
-Kedar
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>