Error deploying my first ESB

[earniedyke]

Greetings all,

I am trying to deploy a simple ESB to ESB 4.2MR2 on Windows XP as follows:

<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb
 xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd"
 parameterReloadSecs="5">

 <providers>
 <jms-provider name="JBossMQ"
 connection-factory="ConnectionFactory"
 jndi-URL="jnp://127.0.0.1:1099"
 jndi-context-factory="org.jnp.interfaces.NamingContextFactory"
 jndi-pkg-prefix="org.jboss.naming:org.jnp.interfaces">

 <jms-bus busid="SimpleQueue">
 <jms-message-filter dest-type="QUEUE"
 dest-name="queue/A" />
 </jms-bus>
 </jms-provider>
 </providers>

 <services>
 <service category="testESB" name="SimpleListener"
 description="Test">
 <listeners>
 <jms-listener name="jmsListener" busidref="SimpleQueue"
 maxThreads="1" is-gateway="true" />
 </listeners>
 <actions>
 <action name="action1"
 class="com.ebs.esb.listener.JMSListener" process="process" />
 </actions>
 </service>
 </services>

</jbossesb>

When I deploy if I receive the following error. Any ideas what I could be doing wrong? I see nothing in any of the documentation, Getting Started, Programmers or Admin guide that indicate I need to register anything.

2007-06-22 08:48:32,968 INFO [org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer] create esb service, JMSTest.esb
2007-06-22 08:48:40,484 INFO [org.apache.juddi.util.Loader] Using the Context ClassLoader
2007-06-22 08:48:40,500 INFO [org.apache.juddi.util.jdbc.ConnectionManager] Using JNDI to aquire a JDBC DataSource with name: java:/juddiDB
2007-06-22 08:48:41,015 WARN [org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle] Unexpected exception caught while initialisation
java.lang.reflect.UndeclaredThrowableException
 at $Proxy9.findEPRs(Unknown Source)
 at org.jboss.soa.esb.listeners.RegistryUtil.getEprs(RegistryUtil.java:212)
 at org.jboss.soa.esb.listeners.gateway.JmsGatewayListener.doInitialise(JmsGatewayListener.java:94)
 at org.jboss.soa.esb.listeners.lifecycle.AbstractManagedLifecycle.initialise(AbstractManagedLifecycle.java:125)
 at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.initialiseInstances(ManagedLifecycleController.java:164)
 at org.jboss.soa.esb.listeners.lifecycle.ManagedLifecycleController.start(ManagedLifecycleController.java:80)
 at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployment.startService(JBoss4ESBDeployment.java:79)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy23.start(Unknown Source)
 at org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer.start(JBoss4ESBDeployer.java:268)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
 at sun.reflect.GeneratedMethodAccessor61.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy7.deploy(Unknown Source)
 at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
 at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
 at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
 at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
 at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
 at $Proxy0.start(Unknown Source)
 at org.jboss.system.ServiceController.start(ServiceController.java:417)
 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:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy4.start(Unknown Source)
 at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
 at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
 at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
 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:585)
 at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
 at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
 at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
 at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
 at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
 at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
 at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
 at $Proxy5.deploy(Unknown Source)
 at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
 at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
 at org.jboss.Main.boot(Main.java:200)
 at org.jboss.Main$1.run(Main.java:490)
 at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.InvocationTargetException
 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:585)
 at org.jboss.internal.soa.esb.services.registry.JAXRRegistryService$1.invoke(JAXRRegistryService.java:59)
 ... 99 more
Caused by: org.jboss.soa.esb.services.registry.RegistryException: Could not find service with category=testESB and serviceName=SimpleListener
 at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:355)
 ... 104 more
Caused by: org.jboss.soa.esb.services.registry.RegistryException: Could not find service with category=testESB and serviceName=SimpleListener
 at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:342)
 ... 104 more

[claudio_br]

Do you have the file jbossesb-properties.xml in classpath of application?
If not, try see the file jbossesb-properties.xml in sample\helloword.

[earniedyke]

Thanks for the reply. What I found was I was missing the ESB listener in my jboss-esb.xml file. Because my service was a gateway service, ESB was requiring the ESB listener as well. Not sure why that would be required.

Earnie!

[tfennelly]

OK, there are a number of potential issues here. Fixing them will help prevent this issue reappearing for other users:

1. JAXRRegistryService doesn't unpack "cause" exception after proxied invocation of Registry.
2. Service configurations without an ESB Message Aware listener should cause an error on startup/redeploy. I think this is valid. Kev/Kurt?

[tfennelly]

As a matter of interest... do you find it odd/confusing that you always have to configure a message aware listener (is-gateway="false"), even when you've defined a gateway listener? Do you think you'd find it easier to understand if there were just "listeners" and that the underlying ESB code figured out if the message was already message-aware/normalized or not?

[earniedyke]

Most certainly it would be easier if you only had to configure one or the other not both. In all honesty the code trivial but it would be one less thing to think about. Just configure your listener as gateway or not and be done with it.

Earnie!

[marklittle]

This is not the first time we've had this issue, so we'll try to address it (make it easier/more intuitive) through the resolution of the issues Tom has raised.

[tfennelly]

This is not the first time we've had this issue, so we'll try to address it (make it easier/more intuitive) through the resolution of the issues Tom has raised.

Both the issues listed above are now resolved and checked in. You'll get an error now if your configuration doesn't include a message-aware listener config and the RegistryService mbean throws the original exception when the underlying Registry impl throws an exception.

[marklittle]

I think we need to add something to the documentation too, right?

[tfennelly]

I think we need to add something to the documentation too, right?

I'll add something, but the most important bit is sorted - the user gets an error when they try to do it. They shouldn't need to poke about in reams of docs for this type of stuff :-)

[marklittle]

Sure, but if they get an error they may want to consult the documentation to figure out why and what to do to fix it. I just want to make sure that all of the bases are covered here in the release. Like I said: this isn't the first time users have been caught by this issue.

[bsheward]

I agree. Was anything documented?

I would like to know what is happening that I must define an ESB aware message listener.

If the service can never perform actions except as a result of the items coming from a gateway listener, why do I need an ESB aware listener defined too? Does the gateway pass the message to the actions via the ESB compliant provider?

If gateways and services were configured differently and I really wanted a service to respond to gateway messages and internal messages, could I chain two services together, so that the gateway service would use the notification action, and have the non-gateway service listen to ESB compliant JMS messages as usual?

Finally, if JMS is the mechanism used to pass messages around the ESB, and could also be used as the gateway mechanism to introduce messages onto the ESB, why do I need to define my SQL Listener as a gateway, when it absolutely must be a gateway, and couldn't not be. The JMS listener seems to be the only one which could introduce ambiguity?

This all seems to be related to registering services and having the registry know whether they support ESB compliant messages or not?

[burrsutter]

I agree. Was anything documented?

I'm not sure if the docs show this clearly. However, the examples/quickstarts do.

I would like to know what is happening that I must define an ESB aware message listener.

If the service can never perform actions except as a result of the items coming from a gateway listener, why do I need an ESB aware listener defined too? Does the gateway pass the message to the actions via the ESB compliant provider?

A service CAN perform actions with only an ESB listener. The native_client quickstart demonstrates this.

If gateways and services were configured differently and I really wanted a service to respond to gateway messages and internal messages, could I chain two services together, so that the gateway service would use the notification action, and have the non-gateway service listen to ESB compliant JMS messages as usual?

A single service can be tied to both a gateway and esb-aware/native listener. quickstart helloworld demonstrates this

Notification is a different animal, it uses "pure" JMS, Files, FTP, etc. So it could not go directly to an esb-aware/native listener/service.

I believe the routers will go native. Review quickstart static_router.

-----------
Let me see if I can explain why there are 2 types of listeners: gateways and esb-aware/native listeners.
gateways are to interact with the outside world, the world that doesn't know about an ESB. It might be a J2SE app that sends a JMS message, a COBOL app that creates a file, a stored procedure that creates a record, a VB app that issues a SOAP request. Those types of clients know nothing about the ESB.

However, you can also have "native" clients, who do understand the ESB and can invoke an ESB service directly without going through a gateway. Those native clients need to be written in Java. Check out the HelloWorldWS.java in the native_client quickstart and look at the ServiceInvoker.

There are also many more gateway protocols/transports supported than native/esb-aware protocols/transports available today. For instance, we have a Hibernate gateway whose job is to register itself for domain object changes and then turn those events into ESB Messages for the native/esb-aware listener which is likely JMS, FTP or File.

The gateway massages the outside worlds input (flat file, XML, http stream, hibernate object, sql resultset) into something the bus can handle. The bus then works off an internal message format (normalized message) that allows all your code/actions to work regardless of initial transport.

[bsheward]

Quote:
I would like to know what is happening that I must define an ESB aware message listener.

If the service can never perform actions except as a result of the items coming from a gateway listener, why do I need an ESB aware listener defined too? Does the gateway pass the message to the actions via the ESB compliant provider?

A service CAN perform actions with only an ESB listener. The native_client quickstart demonstrates this.

Sorry, you misunderstand me. Let me try with an example and rephrasing...

If I have a service, the job of which is to rename files and then drop a message in a queue to allow other services to deal with the file. It uses the File Gateway to listen for files in a directory and then uses a custom action to do the rename. I never ever want this to run outside of the scope of this gateway, yet it seems I am required to define a non-gateway provider. Why? Does the gateway pass the message to the actions via the ESB compliant provider?

A single service can be tied to both a gateway and esb-aware/native listener.

Understood, but to be more specific, it seems that if a single service is tied to a gateway listener, it must also be tied to an esb-aware/native listener. Why?

I understand the difference between plain services and gateway services, I'm just unsure of why I need to define an esb-aware/native listener in addition to a gateway listener in gateway services.

[burrsutter]

Does the gateway pass the message to the actions via the ESB compliant provider?

Yes

it seems that if a single service is tied to a gateway listener, it must also be tied to an esb-aware/native listener . Why?

Yes this is true. It is a requirement of the current implementation/architecture. Your questioning of this item is still great feedback for the team.

I understand the difference between plain services and gateway services, I'm just unsure of why I need to define an esb-aware/native listener in addition to a gateway listener in gateway services.

It is simply a requirement of the ESB 4.x architecture. You always need at a minimum a single native/esb-aware listener from which you can pile on as many gateway listeners as you like. A single native listener can have File, FTP, JMS, HTTP, Hibernate, etc gateways added to it all in a single configuration but you must always start with a minimum of at least one native/esb-aware listener.