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
>