Again, more questions.
3. In core/kernel the ApplicationLifecycle class uses the deployment
logger. Of course it does not find the correct resource bundle (for
deployment) because kernel does not (and should not) depend on any of
the deployment modules. So other more valid uses of the DEPL logger
will come up empty trying to look up strings. I am going to change
ApplicationLifecycle to use the CORE logger instead unless someone objects.
4. After I had started the server I hand-edited the
${domain-dir}/config/logging.properties to change the level for
javax.enterprise.system.tools.deployment and saved the file. When I
tried to deploy an app after that nothing was written to the server log
and the client reported
remote failure: java.lang.StackOverflowError
Command deploy failed.
After I restart the server and leave logging.properties alone I can
deploy successfully.
Has anyone else tried editing logging.properties while the server was
running, and if so has anyone seen something like this after revising
the level for a logger - or after making any change to
logging.properties for that matter?
- Tim
Tim Quinn wrote:
> OK, I am being a good citizen and going through the deployment uses of
> LogDomains.getLogger and changing them all to follow Jerome's
> technique #2.2.
>
> Two questions now:
>
> 1. (which I posed last night) Do we need to add the path where the
> LogStrings.properties resides to the osgi.bundle file for the common
> module?
>
> 2. Where is the root logger and what class should I pass in searching
> for it? There is some code in deployment which tries to find the
> deployment logger and, if that fails, tries to find the root logger
> instead.
> Thanks.
>
> - Tim
>
> 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
>>
>
>