[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> made a comment on [bug 876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274]
verified in soa-p-5.3.1.ER1 by rbalent(a)redhat.com
> SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
> ---------------------------------------------------------------------------------------
>
> Key: JBESB-3772
> URL: https://issues.jboss.org/browse/JBESB-3772
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.10, 4.10 CP1, 4.11
> Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
> Reporter: Duncan Doyle
> Assignee: Tadayoshi Sato
> Labels: esb
> Fix For: 4.11 CP2
>
>
> I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
> One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
> In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> changed the Status of [bug 876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274] from ON_QA to VERIFIED
> SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
> ---------------------------------------------------------------------------------------
>
> Key: JBESB-3772
> URL: https://issues.jboss.org/browse/JBESB-3772
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.10, 4.10 CP1, 4.11
> Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
> Reporter: Duncan Doyle
> Assignee: Tadayoshi Sato
> Labels: esb
> Fix For: 4.11 CP2
>
>
> I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
> One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
> In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> made a comment on [bug 876274|https://bugzilla.redhat.com/show_bug.cgi?id=876274]
> SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
> ---------------------------------------------------------------------------------------
>
> Key: JBESB-3772
> URL: https://issues.jboss.org/browse/JBESB-3772
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.10, 4.10 CP1, 4.11
> Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
> Reporter: Duncan Doyle
> Assignee: Tadayoshi Sato
> Labels: esb
> Fix For: 4.11 CP2
>
>
> I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
> One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
> In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> made a comment on [bug 881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919]
> SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
> ---------------------------------------------------------------------------------------
>
> Key: JBESB-3772
> URL: https://issues.jboss.org/browse/JBESB-3772
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.10, 4.10 CP1, 4.11
> Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
> Reporter: Duncan Doyle
> Assignee: Tadayoshi Sato
> Labels: esb
> Fix For: 4.11 CP2
>
>
> I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
> One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
> In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> changed the Status of [bug 881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919] from VERIFIED to CLOSED
> SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
> ---------------------------------------------------------------------------------------
>
> Key: JBESB-3772
> URL: https://issues.jboss.org/browse/JBESB-3772
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.10, 4.10 CP1, 4.11
> Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
> Reporter: Duncan Doyle
> Assignee: Tadayoshi Sato
> Labels: esb
> Fix For: 4.11 CP2
>
>
> I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
> One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
> In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3772:
------------------------------------------------
Jiri Sedlacek <jsedlace(a)redhat.com> changed the Status of [bug 881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919] from ON_QA to VERIFIED
> SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
> ---------------------------------------------------------------------------------------
>
> Key: JBESB-3772
> URL: https://issues.jboss.org/browse/JBESB-3772
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.10, 4.10 CP1, 4.11
> Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
> Reporter: Duncan Doyle
> Assignee: Tadayoshi Sato
> Labels: esb
> Fix For: 4.11 CP2
>
>
> I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
> One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
> In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months
[JBoss JIRA] (JBESB-3891) Error configuring action processing pipeline
by Deepak Tewani (JIRA)
Deepak Tewani created JBESB-3891:
------------------------------------
Summary: Error configuring action processing pipeline
Key: JBESB-3891
URL: https://issues.jboss.org/browse/JBESB-3891
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Deepak Tewani
Kindly help in debugging the below issue.
Summary about the Environment
1) We are having two different esb box and services box. In Esb box, all esb are deployed and in services box, all services are deployed.
2) WSDL are kepl locally on esb box and jboss-esb.xml is picking up the wsdl by <property name="wsdl" value="file:///opt/AbcBean.wsdl" >
2012-12-19 11:04:46,056 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (Thread-2) Error installing to Start: name=jboss.esb.vfs:///opt/jboss-6.0.0.Final/server/default/deploy/NotificationServiceESB.esb state=Create: org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleException: Error configuring action processing pipeline
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:192) [:]
at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133) [:]
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109) [:]
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66) [:]
at org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment.start(EsbDeployment.java:234) [:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_16]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_16]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_16]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_16]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.system.ServiceController.doInstall(ServiceController.java:653) [:6.0.0.Final (Build SVNTag:JBoss_6.0.0.Final date: 20101228)]
at org.jboss.system.ServiceController.register(ServiceController.java:356) [:6.0.0.Final (Build SVNTag:JBoss_6.0.0.Final date: 20101228)]
at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104) [:6.0.0.Final]
at sun.reflect.GeneratedMethodAccessor312.invoke(Unknown Source) [:1.6.0_16]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_16]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_16]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.system.ServiceController.doChange(ServiceController.java:671) [:6.0.0.Final (Build SVNTag:JBoss_6.0.0.Final date: 20101228)]
at org.jboss.system.ServiceController.start(ServiceController.java:443) [:6.0.0.Final (Build SVNTag:JBoss_6.0.0.Final date: 20101228)]
at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44) [:6.0.0.Final]
at sun.reflect.GeneratedMethodAccessor315.invoke(Unknown Source) [:1.6.0_16]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_16]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_16]
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.0.0.Final]
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.Final]
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_16]
Caused by: org.jboss.soa.esb.ConfigurationException: Unexpected exception during lifecycle initialisation
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.initialise(ActionProcessingPipeline.java:402) [:]
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:188) [:]
... 118 more
Caused by: org.jboss.soa.esb.actions.ActionLifecycleException: Got an error while processing EJB method [initializeQueue]
at org.jboss.soa.esb.actions.AQEJBProcessor.initialise(AQEJBProcessor.java:58) [:]
at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.initialise(OverriddenActionLifecycleProcessor.java:123) [:]
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.initialise(ActionProcessingPipeline.java:397) [:]
... 119 more
Caused by: org.jboss.soa.esb.actions.ActionLifecycleException: Could not lookup NotificationAQListenerBean/remote
at org.jboss.soa.esb.actions.AQEJBProcessor.getEjb3FromJndi(AQEJBProcessor.java:90) [:]
at org.jboss.soa.esb.actions.AQEJBProcessor.initialise(AQEJBProcessor.java:53) [:]
... 121 more
Caused by: javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.20.90.173:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out]
at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1690)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1761)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:695)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at org.jboss.soa.esb.actions.AQEJBProcessor.getEjb3FromJndi(AQEJBProcessor.java:87)
at org.jboss.soa.esb.actions.AQEJBProcessor.initialise(AQEJBProcessor.java:53)
at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.initialise(OverriddenActionLifecycleProcessor.java:123)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.initialise(ActionProcessingPipeline.java:397)
at org.jboss.soa.esb.listeners.message.MessageAwareListener.doInitialise(MessageAwareListener.java:188)
at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:133)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:109)
at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:66)
at org.jboss.soa.esb.listeners.deployers.mc.as6.EsbDeployment.start(EsbDeployment.java:234)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257)
at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125)
at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72)
at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641)
at org.jboss.system.ServiceController.doInstall(ServiceController.java:653)
at org.jboss.system.ServiceController.register(ServiceController.java:356)
at org.jboss.system.microcontainer.jmx.ServiceControllerRegistrationLifecycleCallback.install(ServiceControllerRegistrationLifecycleCallback.java:104)
at sun.reflect.GeneratedMethodAccessor312.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305)
at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018)
at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091)
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654)
at org.jboss.system.ServiceController.doChange(ServiceController.java:671)
at org.jboss.system.ServiceController.start(ServiceController.java:443)
at org.jboss.system.microcontainer.jmx.ServiceControllerStartStopLifecycleCallback.install(ServiceControllerStartStopLifecycleCallback.java:44)
at sun.reflect.GeneratedMethodAccessor315.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60)
at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168)
at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300)
at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305)
at org.jboss.dependency.plugins.AbstractLifecycleCallbackItem.install(AbstractLifecycleCallbackItem.java:87)
at org.jboss.dependency.plugins.AbstractController.handleLifecycleCallbacks(AbstractController.java:2018)
at org.jboss.dependency.plugins.AbstractController.handleInstallLifecycleCallbacks(AbstractController.java:1983)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1091)
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182)
at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58)
at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654)
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679)
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106)
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143)
at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151)
at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083)
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654)
at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190)
at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87)
at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215)
at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159)
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112)
at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87)
at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91)
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132)
at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56)
at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827)
at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.SocketTimeoutException: Receive timed out
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136)
at java.net.DatagramSocket.receive(DatagramSocket.java:712)
at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:1659)
... 127 more
[Root exception is javax.naming.CommunicationException: Failed to connect to server /10.20.90.173:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server /10.20.90.173:1099 [Root exception is java.net.ConnectException: Connection refused]]]
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1780) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:695) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final]
at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_16]
at org.jboss.soa.esb.actions.AQEJBProcessor.getEjb3FromJndi(AQEJBProcessor.java:87) [:]
... 122 more
Caused by: javax.naming.CommunicationException: Failed to connect to server /10.20.90.173:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server /10.20.90.173:1099 [Root exception is java.net.ConnectException: Connection refused]]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:337) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1746) [:5.0.5.Final]
... 126 more
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server /10.20.90.173:1099 [Root exception is java.net.ConnectException: Connection refused]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:307) [:5.0.5.Final]
... 127 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method) [:1.6.0_16]
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) [:1.6.0_16]
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) [:1.6.0_16]
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) [:1.6.0_16]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) [:1.6.0_16]
at java.net.Socket.connect(Socket.java:525) [:1.6.0_16]
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:97) [:5.0.5.Final]
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:82) [:5.0.5.Final]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:303) [:5.0.5.Final]
... 127 m
I have tried to deploy the esb with
deployment.xml
<jbossesb-deployment>
<depends>jboss.esb:deployment=jbossesb.esb</depends>
<depends>jboss.esb:deployment=soap.esb</depends>
<depends>jboss.esb:deployment=spring.esb</depends>
<depends>jboss.esb:deployment=jbrules.esb</depends>
</jbossesb-deployment>
and also tried with deployment.xml
<jbossesb-deployment>
<depends>jboss.esb:deployment=jbossesb.esb</depends>
<depends>jboss.esb:deployment=soap.esb</depends>
<depends>jboss.esb:deployment=spring.esb</depends>
</jbossesb-deployment>
But in both cases it is giving same exception
Also tried on both jboss-6.0.0 and jboss-5 .1.0 but same exception.
Kindly help
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 4 months