Unnecessary XML configuration for internal jms listener

[thomasra]

In most scenarios, when configuring new services one simply creates a new jms queue and configures this as the internal jms listener for the service. In my opinion this isn't really about configuring a service, but rather it is an aspect of the ESB design.

This could probably just be removed in favor of a default, provided, jms listener, or (more preferably) be kept solely as an override, should the user wish to reference specific queues.

[beve]

Hi,

There is the inVM transport where you don't need to define an internal listener:

 <!-- Set the invmScope attribute to "GLOBAL". Make "GLOBAL" the default in the ESB properties file! -->
 <service category="HelloWorld" name="Service1" description="Service 1" invmScope="GLOBAL">
 <listeners>
 <!-- So we just need to define a Gateway to the service... -->
 <jms-listener name="JMS-Gateway" busidref="quickstartGwChannel" is-gateway="true"/>
 </listeners>
 <actions>
 ...

This might not be in the version that you are running but if you care to take a closer look at this you can checkout the invm_transport1 quickstart in the main subversion trunk.

Regards,

/Daniel

[thomasra]

Yes, I'm aware of the in-vm listener. :) Still relevant, though. What I'm talking about is this:

<!-- Set the invmScope attribute to "GLOBAL". Make "GLOBAL" the default in the ESB properties file! -->
 <service category="HelloWorld" name="Service1" description="Service 1" invmScope="GLOBAL">
 <actions>
 ...

I don't see why a service needs to specify any internal jms listeners unless one needs to "stray" off the default path?

[tfennelly]

"thomasra" wrote:
Yes, I'm aware of the in-vm listener. :) Still relevant, though. What I'm talking about is this:

<!-- Set the invmScope attribute to "GLOBAL". Make "GLOBAL" the default in the ESB properties file! -->
 <service category="HelloWorld" name="Service1" description="Service 1" invmScope="GLOBAL">
 <actions>
 ...

I don't see why a service needs to specify any internal jms listeners unless one needs to "stray" off the default path?

[tfennelly]

hmmmm.... not sure what happened there... sorry...

What I asked in that post was... where is the JMS listener you're referring to? The config you posted there has no listener config.

If you're talking about having to specify the inVMScope attribute... read the docs... there you'll see you can change the default (in the jbossesb-properties.xml) to be GLOBAL. Then you won't need to define this attribute unless you want to disable InVM for a service.

[thomasra]

Okay, I'll try to be a little more precise here.

It would be much clearer (in my opinion) if the entire internal jms configuration was just there as a potential override, allowing a service to be configured directly relating to what a user wants to know about:

How we interact with this service (gateways)
The pipeline (actions)
etc

How the ESB chooses to bridge a gateway with the action pipeline isn't really interesting in most scenarios (except when one would want to override).

But this is only a minor issue. :)

[thomasra]

Hehe.

Yes, my configuration had no listeners in it at all. Which is what I think is a good idea - it would merely default to the in-vm transport and an automatically configured bus reference?

[tfennelly]

"thomasra" wrote:
Okay, I'll try to be a little more precise here.

It would be much clearer (in my opinion) if the entire internal jms configuration was just there as a potential override, allowing a service to be configured directly relating to what a user wants to know about:

How we interact with this service (gateways)
The pipeline (actions)
etc

How the ESB chooses to bridge a gateway with the action pipeline isn't really interesting in most scenarios (except when one would want to override).

But this is only a minor issue. :)

Sure... in v5.x of the ESB... routing and service configurations will be separated away each other (in separate files if you so wish).

[tfennelly]

"thomasra" wrote:
Hehe.

Yes, my configuration had no listeners in it at all. Which is what I think is a good idea - it would merely default to the in-vm transport and an automatically configured bus reference?

OK... and this is possible wrt local service routing. You don't need to define any listeners and if you change the default in the jbossesb-properties.xml, you don't need to define the inVMScope attribute.

In terms of remote service routing "on the bus"... v5.0 will hide a lot of this stuff in the way you describe.

[jjarkko]

We solved the problem by creating a set of XSL (three to be exact) files which search jboss-esb.xml's service elements for jms busrefs and create both jbm-queue-service.xml and jbmq-queue-service.xml and ALSO updates the relevant section (Adding jms-bus elements under providers/jms-provider ) in jboss-esb.xml.

The jms-bus information is already extracted to a separate xml-file just waiting for ESB deployer to understand it ;) Currently the generated jmsbusses.xml is injected back to jboss-esb.xml using replaceregexp ant task.

We're quite happy with this solution. Before we had couple of ESB services talking and listening to a wrong JMS queue, which caused a lot of havoc.

[karypid]

Could you share this tool with us on the forum? I'd love to generate the jms queue configurations automatically.

By the way, can anyone from the JBossESB team tell us if they're working with the JBossTools team to augment the developer suite with ESB tooling support?

[karypid]

I searched a little regarding the tooling and the only interesting ESB-related thing on the roadmap for JBoss Tools 3.x is the ability to automate deployment via a WTP module. Not much, but still useful...

More info here: http://wiki.jboss.org/wiki/JBossToolsRoadmap.