dev@glassfish.java.net

Re: logger changes - this will help you

From: Carla Mott <Carla.Mott_at_Sun.COM>
Date: Fri, 19 Sep 2008 23:41:56 -0700

Hi,

the code that calls readConfiguration is in LogMangerService. I see that
it is getting called when I change the logging.properties file. Where is
the logging.properties file you are using exactly?



Jan Luehe wrote:
> Hi Carla,
>
> On 09/19/08 05:57 PM, Carla Mott wrote:
>>
>> What is supposed to happen is when you save the file that should
>> trigger the readConfiguration to be called. I know that there is a
>> bug on this since in at least one case there is an infinite loop which
>> means the logger is reconfigured.
>>
>> Not sure why you are not seeing the change. Is the logger name
>> correct? I copied what was in LogDomains.java but maybe I made a
>> mistake. Can you make the change and restart the server and see if
>> the change took affect so we know the logger is correct.
>
> Yes, that's what I did: Uncomment the line (for the web logger) in
> logging.properties and restart the server.
> When I add a breakpoint in
> java.util.logging.LogManager.readConfiguration(), I see only the
> logging.properties
> from my JRE getting read, but never the one from my domain.
>
>
> Jan
>
>
>>
>> I'm looking into the infinite loop bug. I will make sure the
>> configuration is getting updated as part of that.
>>
>> carla
>>
>>
>> Jan Luehe wrote:
>>> Thanks, Carla!
>>>
>>> I'm having trouble setting the log level of the web related logger to
>>> FINE.
>>>
>>> To do this, I've edited my domain's logging.properties and uncommented
>>> this line:
>>>
>>> javax.enterprise.system.container.web.level=FINE
>>>
>>> I understand that the settings in my domain's logging.properties are
>>> supposed
>>> to become effective by a call to
>>> java.util.logging.LogManager.readConfiguration(),
>>> which parses the logging properties file referenced by the
>>> "java.util.logging.config.file"
>>> system property. In v3, this system property points to the domain's
>>> logging.properties.
>>>
>>> I understand that all this is supposed to get triggered by
>>> LogMangerService.postConstruct(), yet I don't see this method ever
>>> getting
>>> called, which is why my domain's logging.properties is never getting
>>> parsed ...
>>>
>>>
>>> Jan
>>>
>>>
>>> On 09/19/08 04:44 PM, Carla Mott wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Jerome and I talked this morning and we think the code I just
>>>> commited will help you. I modified LogDomains.java to in addition
>>>> to looking for the resource bundle in the bundle of the calling
>>>> class to also look in the common-util bundle (where LogDomains is)
>>>> which is where most LogStrings.properties files are now.
>>>>
>>>>
>>>> This reduces the urgency of moving those files now and we can wait
>>>> to move them after prelude v3 is out.
>>>>
>>>> This time I ran the quicklook tests and didn't undeploy the tests.
>>>> I then reran the tests again, restarting the server with the tests
>>>> and both times the tests passed.
>>>>
>>>> Hope this helps,
>>>> Carla
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>