Carla Mott wrote:
> Sorry if I was not clear. The first time the server is started after
> installation the logging config info is moved. Logging config info is
> then contained in only one place and that is the logging.properties file.
Ok. What about the directive in the *Logging JSR*?
If more sophisticated configuration is required, then a Java class can
be used to programatically define the configuration
I think we have fairly sophisticated logging with different log-levels
for different loggers. The names of various loggers that subsystems
use also needs to be documented. In a clustering scenario, maintaining
every new file is a headache ....
Let me ask -- how hard is it to implement what this API says:
http://java.sun.com/javase/6/docs/api/java/util/logging/LogManager.html#readConfiguration(java.io.InputStream)
(It accepts an input stream. It appears that all it needs a stream that
provides simple properties. It's not tied to a physical file
logging.properties).
-Kedar
> thanks,
> Carla
>
> Kedar Mhaswade wrote:
>>
>>
>> Carla Mott wrote:
>>> At server startup the log-service element is "moved" to
>>> logging.properties and that element is then removed from domain.xml.
>>
>> Please say that this is temporary or untrue. (It's April 1st today).
>>
>> Every startup does not have to do this. If we have moved to
>> logging.properties,
>> we look at only logging.properties and nowhere else.
>>
>> This dual handling is error-prone and wrong.
>>
>> Alternatively, we can stick to domain.xml and introduce a class that
>> provides the configuration to logging subsystem. JSR-47 PFD says the
>> following
>> in this regard:
>>
>> The configuration file is intended to support fairly simple
>> configuration.
>> If more sophisticated configuration is required, then a Java class can
>> be used to programatically
>> define the configuration (see Section 2.11 below). (From Java Logging
>> JSR spec).
>>
>> I urge you to reconsider the need of logging.properties, if possible.
>>
>> -Kedar
>>
>>
>>
>>> I do have a set APIs that allow you to access the values of all the
>>> elements that were in log-service. See LoggingConfigImpl
>>> common/common-util for specifics.
>>>
>>> I searched the code looking for "log-service" and the config bean
>>> LogService but didn't see anything in the web container code.
>>>
>>> Carla
>>>
>>> Jan Luehe wrote:
>>>>
>>>>> This looks like an issue with the web container code at least in
>>>>> part. We're looking at this now and hope to have it resolved soon.
>>>>
>>>> I think I understand what's going on:
>>>>
>>>> In GlassFish v2.1, each virtual-server came with its own "log-file"
>>>> attribute:
>>>>
>>>> <virtual-server hosts="${com.sun.aas.hostName}"
>>>> http-listeners="http-listener-1,http-listener-2" id="server"
>>>> log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
>>>>
>>>> In addition, log-service also specified a log file, using its "file"
>>>> attribute:
>>>>
>>>> <log-service alarms="false"
>>>> file="${com.sun.aas.instanceRoot}/logs/server.log" [...]>
>>>>
>>>> By default, a virtual-server's "log-file" would match the log-service's
>>>> "file", but in case they were different, the container would create an
>>>> individual, time-stamped log file for the virtual-server.
>>>>
>>>> In GlassFish v3, there is code in WebContainer.java which still
>>>> attempts
>>>> to read the log-service element and its "file" attribute from
>>>> domain.xml,
>>>> even though they've been deprecated and are no longer specified in
>>>> domain.xml (they've been superseded by the new "logging.properties").
>>>>
>>>> A virtual-server's "log-file" now defaults to the domain's server.log,
>>>> which is different from "null" (which is what the log-service's "file"
>>>> evaluates to, since log-service no longer exists). Therefore, the
>>>> web container interprets this to mean that each virtual-server should
>>>> be configured with its own, time-stamped log file.
>>>>
>>>> The code in WebContainer.java needs to be changed so that it no longer
>>>> attempts to read log-service or any of its attributes from domain.xml.
>>>>
>>>>
>>>> Jan
>>>>
>>>>
>>>>>
>>>>> Cheng Fang wrote:
>>>>>> I'm using v3 latest promoted build (3/26/2009). After running the
>>>>>> server for a while, I noticed there are 2 server.log files, both
>>>>>> are actively logged:
>>>>>>
>>>>>> /v3/glassfish/domains/domain1/logs > ll
>>>>>> total 480
>>>>>> -rw-r--r-- 1 staff 58938 Mar 27 22:40 server.log
>>>>>> -rw-r--r-- 1 staff 176221 Mar 27 22:40 server_2009-03-27.log
>>>>>> -rw-r--r-- 1 staff 4096 Mar 27 21:50 jvm.log
>>>>>>
>>>>>> server.log and server_2009-03-27.log have the same timestamp.
>>>>>> What's more interesting is, autodeploy and EJB events are logged
>>>>>> into server.log, and web container events are logged to
>>>>>> server_2009-03-27.log. I was looking for errors in server.log
>>>>>> after my app failed but couldn't find any as they have been
>>>>>> diverted to server_2009-03-27.log.
>>>>>>
>>>>>> The format of server_2009-03027 (see below) is different from
>>>>>> server.log. At least its dateTime format is different from
>>>>>> server.log.
>>>>>>
>>>>>> Any idea what's happening here?
>>>>>>
>>>>>> 2009-03-27 18:14:18 createObjectName with
>>>>>> StandardEngine[com.sun.appserv].StandardHost[__asadmin]
>>>>>> 2009-03-27 18:14:18 createObjectName with
>>>>>> StandardEngine[com.sun.appserv].StandardHost[server]
>>>>>> 2009-03-27 21:50:18 createObjectName with
>>>>>> StandardEngine[com.sun.appserv].StandardHost[__asadmin]
>>>>>> 2009-03-27 21:50:18 preRegister with
>>>>>> com.sun.appserv:type=Logger,host=__asadmin
>>>>>> 2009-03-27 21:50:18 createObjectName with
>>>>>> StandardEngine[com.sun.appserv].StandardHost[server]
>>>>>> 2009-03-27 21:50:18 preRegister with
>>>>>> com.sun.appserv:type=Logger,host=server
>>>>>> 2009-03-27 22:23:12 StandardWrapperValve[Servlet1]: PWC1406:
>>>>>> Servlet.service() for servlet Servlet1 threw exception
>>>>>> java.lang.ClassCastException: java.lang.String cannot be cast to
>>>>>> java.util.concurrent.Future
>>>>>>
>>>>>> 2009-03-27 22:40:02 StandardWrapperValve[Servlet1]: PWC1406:
>>>>>> Servlet.service() for servlet Servlet1 threw exception
>>>>>> java.lang.ClassCastException: java.lang.String cannot be cast to
>>>>>> java.util.concurrent.Future
>>>>>>
>>>>>> -cheng
>>>> ---------------------------------------------------------------------
>>>> 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
>