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)?
thanks,
-marina
Jan Luehe wrote:
> The logging resource bundle files for the web, ejb, and appclient
> containers currently all reside in common/common-util:
>
>
> src/main/java/com/sun/logging/enterprise/system/container/appclient/LogStrings.properties
>
>
>
> src/main/java/com/sun/logging/enterprise/system/container/ejb/mdb/LogStrings.properties
>
>
>
> src/main/java/com/sun/logging/enterprise/system/container/ejb/LogStrings.properties
>
>
>
> src/main/java/com/sun/logging/enterprise/system/container/web/LogStrings.properties
>
>
>
> I believe the plan is to move them into their respective container
> modules (i.e., to web/web-glue in the case of the web container)?
>
> Is the plan for loggers to still be acquired by a call to
> com.sun.logging.LogDomains.getLogger()?
>
> If so, we need to:
>
> - Fix its getResourceBundle() method, which currently returns null
>
> - Come up with a package naming convention for the LogStrings.properties
> in the individual container modules, so that LogDomains.getLogger() will
> be able to derive the fully qualified resource name of
> LogStrings.properties for a given Logger
>
> I'd like to help with this, since none of the web container log message
> keys
> are getting expanded to corresponding log messages right now.
>
> Thanks,
>
> Jan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>