Tim,
I have similar questions for the AMX area, which had a too-complicated
system in V2 (due in part to a client and server portion).
The LogDomains.getLogger() facility is more convenient than @Inject:
many, many classes might need the logger, which means that either the
injected logger would have to be passed around (very awkward), or made
available to all the module's classes by the equivalent of
LogDomains.getLogger().
Perhaps there is a hybrid solution, whereby the V3 runtime creates the
Logger based on the module name or other specified value, and injects
the appropriate logger wherever @Inject is used. But that leaves the
question of how to pass the Logger to supporting module code that
wants to use logging, but does not want to or cannot depend on @Inject.
Lloyd
On Jun 22, 2008, at 1:53 PM, Tim Quinn wrote:
> In v2 there were a variety of loggers, specific to various areas of
> the app server, available via the LogDomains.getLogger method.
>
> In v3 I know a service can use @Inject Logger logger; to get a
> logger. Based on a quick experiment, that logger's name is "global."
>
> For classes that are new in v3, what's the preferred way to get the
> appropriate logger? Even if LogDomains.getLogger maintains backward
> compatibility, it that how new classes should get a logger?
>
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc