At server startup the log-service element is "moved" to
logging.properties and that element is then removed from domain.xml. 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
>