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.
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