Jerome Dochez wrote:
>
> 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.
Is it coming for Prelude?
>
>>
>>
>> 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)
I'd prefer for e.g. transaction module to own its logging messages (vs. ask GF
to load them for me). To own the messages, I'd need them be moved from
common/common-util to the appropriate transaction module.
Do you see a problem with that?
thanks,
-marina
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>