The frequency of starting/stopping a component is going to be quite low.
We do believe this
message warrants being logged at the INFO level. If we don't log these
messages, then it would
be very difficult to troubleshoot a problem related to component states,
because we wouldn't
have any indication in the log about when a component was started/stopped.
Remember a component is effectively a container. Not logging anything
when a component is
stopped or started would be analogous to not logging anything when a web
container or EJB
container is stopped or started.
I see a lot more clutter in server.log at the INFO level from other
areas, such as this:
[#|2007-04-24T11:22:03.484-0700|INFO|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_EB1101:
run:EMBEDDED broker started with code =0|#]
[#|2007-04-24T11:22:03.640-0700|INFO|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_RA1101:
SJSMQ JMS ResourceAdaapter configuration=
raUID =null
brokerType =EMBEDDED
brokerInstanceName =imqbroker
brokerBindAddress =null
brokerPort =9099
brokerHomeDir
=C:/d/open2/open-esb/install/as8\imq\bin\..
brokerVarDir
=C:/d/open2/open-esb/install/as8/domains/domain1\imq
brokerJavaDir =c:/Java/jdk1.5.0_09
brokerArgs =null
brokerStartTimeout =60000
adminUsername =admin
adminPassFile =C:\d\tmp\asmq7703.tmp
useJNDIRmiServiceURL =true
rmiRegistryPort =8886
startRmiRegistry =false
useSSLJMXConnector =true
brokerEnableHA =false
clusterId =null
brokerId =null
jmxServiceURL =null
dbType =null
dbProps ={}
dsProps ={}
ConnectionURL =
UserName =guest
ReconnectEnabled =true
ReconnectInterval =5000
ReconnectAttempts =3
AddressListBehavior =RANDOM
AddressListIterations =3
InAppClientContainer =false
InClusteredContainer =false
GroupName =null
|#]
[#|2007-04-24T11:22:03.640-0700|INFO|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_RA1101:
start:SJSMQ JMSRA Connection Factory
Config={imqOverrideJMSPriority=false, imqConsumerFlowLimit=1000,
imqOverrideJMSExpiration=false, imqAddressListIterations=3,
imqLoadMaxToServerSession=true, imqConnectionType=TCP,
imqPingInterval=30, imqSetJMSXUserID=false, imqConfiguredClientID=,
imqSSLProviderClassname=com.sun.net.ssl.internal.ssl.Provider,
imqJMSDeliveryMode=PERSISTENT, imqConnectionFlowLimit=1000,
imqConnectionURL=
http://localhost/imq/tunnel, imqBrokerServiceName=,
imqJMSPriority=4, imqBrokerHostName=localhost, imqJMSExpiration=0,
imqAckOnProduce=, imqEnableSharedClientID=false, imqAckTimeout=0,
imqAckOnAcknowledge=, imqConsumerFlowThreshold=50,
imqDefaultPassword=guest, imqQueueBrowserMaxMessagesPerRetrieve=1000,
imqDefaultUsername=guest, imqReconnectEnabled=false,
imqConnectionFlowCount=100, imqAddressListBehavior=PRIORITY,
imqReconnectAttempts=3, imqSetJMSXAppID=false,
imqConnectionHandler=com.sun.messaging.jmq.jmsclient.protocol.tcp.TCPStreamHandler,
imqSetJMSXRcvTimestamp=false, imqBrokerServicePort=0,
imqDisableSetClientID=false, imqSetJMSXConsumerTXID=false,
imqOverrideJMSDeliveryMode=false, imqBrokerHostPort=7676,
imqQueueBrowserRetrieveTimeout=60000, imqSetJMSXProducerTXID=false,
imqSSLIsHostTrusted=false, imqConnectionFlowLimitEnabled=false,
imqReconnectInterval=5000, imqAddressList=localhost:9099,
imqOverrideJMSHeadersToTemporaryDestinations=false}|#]
[#|2007-04-24T11:22:03.640-0700|INFO|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10;_ThreadName=main;|MQJMSRA_RA1101:
SJSMQ JMSRA Started|#]
kedar wrote:
> Thank you, Mark.
>
> Is it required that the user sees that the binding components
> are being restarted? Is this log record required to be at the
> default ("INFO") log level?
>
> Kedar
>
> Mark S White wrote:
>> JBI is not stopping and starting up. What you are seeing is that once
>> a deployment has been
>> made to a component (such as the Java EE engine or the HTTP binding),
>> whenever the
>> system restarts, the component must be initialized in order to inform
>> it of the existing deployments.
>> This is required by the JSR208 specification, as components are not
>> required to persist any
>> deployment information. In the case you are seeing, the components
>> had a desired state of
>> shutdown, so after the initialization was done, JBI has shut down the
>> components to return
>> them to their desired states. JBI itself did not stop, it only
>> started. The component shutdowns
>> were part of the startup processing.
>>
>> kedar wrote:
>>> More often than not, upon server startup, I see messages like:
>>>
>>> [#|2007-04-24T11:08:11.503-0700|INFO|sun-appserver9.1|javax.enterprise.system.core|_ThreadID=10;_ThreadName=main;|Application
>>> server startup complete.|#]
>>>
>>> [#|2007-04-24T11:21:38.233-0700|INFO|sun-appserver9.1|com.sun.jbi.framework|_ThreadID=17;_ThreadName=sun-javaee-engine;|JBIFW1166:
>>> Engine sun-javaee-engine has been shut down.|#]
>>>
>>> [#|2007-04-24T11:21:38.236-0700|INFO|sun-appserver9.1|sun-http-binding.com.sun.jbi.httpsoapbc.HttpSoapBindingLifeCycle|_ThreadID=18;_ThreadName=sun-http-binding;|HTTP
>>> SOAP binding shutdown completed.|#]
>>>
>>> [#|2007-04-24T11:21:38.236-0700|INFO|sun-appserver9.1|com.sun.jbi.framework|_ThreadID=18;_ThreadName=sun-http-binding;|JBIFW1166:
>>> Binding sun-http-binding has been shut down.|#]
>>>
>>> [#|2007-04-24T11:21:38.238-0700|INFO|sun-appserver9.1|com.sun.jbi.framework|_ThreadID=16;_ThreadName=httpSSLWorkerThread-4848-0;|JBIFW0012:
>>> JBI framework startup complete.|#]
>>>
>>>
>>> Why is JBI stopping and then starting up?
>>>
>>> Thanks,
>>> Kedar
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
--
Open ESB Community (http://open-esb.org)
Check out my blog (http://blogs.sun.com/mwhite)