We don't have to have the info in 2 places, domain.xml and
logging.properties. Currently the only way to get the values is through
some new APIs I created. The long term plan is to rework the server
bean LogService so that it will talk to the logging.properties file
instead of domain.xml. This turns out to be nontrivial and we are
working on that.
I thought that I searched the repository for LogService and didn't see
much but I just searched again and I do see that the web container uses
it in several places. Not sure how I missed this the first time.
Thanks,
Carla
Jan Luehe wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>