On 04/ 1/09 11:42 AM, Carla Mott wrote:
> 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.
That would be great!
> This turns out to be nontrivial and we are working on that.
OK.
For the time being, I will change the web container code to determine
the log file from
LoggingConfigImpl.getLoggingProperties()
Thanks, Carla!
Jan
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>