On 08/25/08 09:33 PM, Tim Quinn wrote:
> Marina Vatkina wrote:
>> Jan,
>>
>> Unfortunately it's a problem for all the modules: in v2 all serious
>> log messages were owned by the appserv-commons, and they went
>> together to the corresponding area in v3 :(. To add to the
>> complexity, in v3 some of our modules now have sub-modules, and it's
>> a question which one should own the messages...
>>
>> May be we should switch to use JDK logger (and pass in the bundle name)?
> I've also been wondering - and asking - about this for a while. I
> recall reading somewhere, some time ago, that the plan was indeed to
> shift to using the JDK logger. There is a logging.properties in the
> domains/${domain-name}/config directory, and that file's settings do
> indeed affect logging if you use Logger.getLogger(someName). If you
> do that in a @Service then it seems to work more smoothly if you
> invoke Logger.getLogger in the postConstruct method. A static or
> instance initializer does not seem guaranteed to pick up the GlassFish
> logging.properties file in domains/${domain-name}/config.
> There is also @Inject Logger logger which injects the global logger.
> I do not know if there is a way to use that to get a logger more
> specific to the current class or package or module.
>
> Further, I am not sure what if any effect the v2-style logging
> settings in domain.xml have. A long time ago I tried an experiment
> changing some of those but did not see any effect. Of course that
> behavior may have changed since then.
In V2, com.sun.enterprise.server.logging.ServerLogManager used to be
responsible for initializing the various module loggers with their log
levels specified in the <log-service> in domain.xml, and to add the
FileandSyslogHandler to them.
I believe in V3, the responsibility for doing this has been, or will be,
delegated to each individual module.
Maybe we can discuss logging at today's eng meeting? I will be joining
late, since I have a meeting conflict.
Thanks,
Jan
>
> Because my experiments with LogDomains were not working but those
> using the standard JDK logger were, and without guidelines for how to
> proceed, I've been using the JDK-style logging in the classes I've
> been working on lately in which I wanted to include or enhance logging
> and it has seemed to be working well.
>
> For what it's worth...
>
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>