On Aug 26, 2008, at 2:51 PM, Marina Vatkina wrote:
> 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?
yes
>
>>>
>>>
>>> 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?
no this would actually be the preferred way, by all means do it asap...
>
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>