Have you looked at using the @DuckTyped annotation to pull that
LogService bean from the habitat so that it looks like it's all part of
the same document that the hk2 code overlays now? The LogService bean
could then have it's own set of document listeners, etc. but would
appear to be one homogenous whole like we have now.
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. 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>