Re: [V3] Question about LogStrings.properties
Jerome Dochez wrote:
>
> 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
Any updates on this ?.
regards,
kumar
>
>>
>>>>
>>>>
>>>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>