On 03/31/09 08:52 PM, 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.
On a second thought, should Config#getLogService continue to return a
non-null LogService in GlassFish v3 that was initialized with the properties
from logging.properties, including having its getFile() return the value
of the
com.sun.enterprise.server.logging.GFFileHandler.file property from
logging.properties?
Jan
>
>
> 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
>