See below.
Kedar Mhaswade wrote:
>
>
>
>>> do I have to use LogDomains.getLogger(ADMIN_LOGGER)?
>>
>> Just to be clear. there is no LogDomains.getLogget(String name) API.
>> You must supply a class object. The reason is because I use that to
>> get the classloader needed when getting the resource bundle.
>
> Ah, yes. This is a change from V2 -- see this link from V2 sources.
>
> http://fisheye5.cenqua.com/browse/glassfish/appserv-commons/src/java/com/sun/logging/LogDomains.java?r=1.8
>
>
> And I agree this change is required, because from a string, you probably
> can't find out the class loader in v3. This is a change worth noting,
> for developers.
>
>>
>> Logger.getLogger("javax.enterprise.system.tools.admin") will return
>> the logger with associated resource bundle as long as the logger has
>> already been created. If not there then it will create a logger for
>> you. The mapping between the resource bundle and the logger names is
>> in the LogDomains.java file.
>
> Looking at LogDomains.java, it's not clear to me how one can get to the
> ResourceBundle based on a name which is just a string. Can you please
> elaborate?
The resource bundle is found using the resource bundle name, locale and
classloader. I get the classloader from the class object that was
passed and use Locale.getDefault() to get the locale.
>
> Also, we have following flavors of LogDomains.java in v3 workspace:
> ./common/common-util/src/main/java/com/sun/common/util/logging/LogDomains.java
>
> ./common/common-util/src/main/java/com/sun/logging/LogDomains.java
> ./deployment/dol/src/main/java/com/sun/enterprise/deployment/util/LogDomains.java
>
> ./web/web-glue/src/main/java/com/sun/enterprise/web/logging/pwc/LogDomains.java
>
>
> of which
>
> ./deployment/dol/src/main/java/com/sun/enterprise/deployment/util/LogDomains.java
>
>
> says it is here for backward compatibility reasons. What does it mean?
> Is this
> class our "public" interface? Sorry for all these questions, but it is
> not clear
> to me.
>
My plan was to update the API using the existing files and when things
are working then deal with the different files. Most call back to
com.sun.logggin.LogDomains.java but at least the one under dol does not.
Not sure what it means that it is there for backward compatibility.
That is part of the next step.
CArla
> -Kedar
>
>
>>
>>>
>>> Are you expecting that none
>>>> will be used?
>>>
>>>>> Carla -- can you please modify the default logging.properties (yes,
>>>>> logging.properties, not LogStrings.properties) with the names of
>>>>> some of our
>>>>> loggers (e.g. WEB, ADMIN, ROOT etc.) so that people can get used to
>>>>> their names?
>>>>> This will also help users know which subsystem in v3 Prelude uses
>>>>> which logger.
>>>>> This is all the more important since we have no tool support in
>>>>> Prelude.
>>>>
>>>> I have added a bunch already. I will add the rest. Look at the end
>>>> of the file and they are all commented out for now.
>>> Where did you add it? I must be missing something. Attached is my
>>> logging.properties from the latest web.zip. (Also, can you tell me where
>>> you have checked in the logging.properties?
>>>
>>> Thanks.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> 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
>