On Aug 26, 2008, at 2:30 PM, Marina Vatkina wrote:
> Jerome,
>
> Can you update us on the upcoming changes that you mentioned at the
> meeting today?
yes as soon as it's ironed out.
>
>
> Will they expect each module to have the corresponding bundle
> locally (i.e. moved out of the common/common-util and split as
> needed)?
>
no the expectation is that you will provide a class which class loader
will be capable of loading the resource bundle you are looking for so
it could be obtained through another bundle importation (assuming that
bundle exports it)
Jerome
> thanks,
> -marina
>
> Jan Luehe wrote:
>> 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
>>>
>> ---------------------------------------------------------------------
>> 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
>