> 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