[objectiser]

Looks like the problem has gone away - was using a text editor to add the code into the example, so may have inadvertantly included a control character or something.

So no problem after all.

[marklittle]

Glad it's sorted now.

[tfennelly]

Gary... you might also be interested in looking at the following integration test for that LogicalEPR functionality...

http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/qa/junit/src/org/jboss/soa/esb/epr

LogicalEPRUnitTest.java is the starting point.

[objectiser]

Ok thanks Tom I will have a look.

In the meantime I have tried using the LogicalEPR in the helloworld service action to use the JMSEpr from the replyTo field on the inbound message to send a response:

org.jboss.soa.esb.addressing.PortReference ref=
message.getHeader().getCall().getReplyTo().getAddr();

org.jboss.soa.esb.addressing.eprs.LogicalEPR lepr=
new org.jboss.soa.esb.addressing.eprs.LogicalEPR(ref);

message.getBody().add("This is the response");
message.getHeader().getCall().setTo(lepr);
message.getHeader().getCall().setReplyTo(null);

System.out.println("NOTIFY: "+message);

lepr.getServiceInvoker().deliverAsync(message);

return null;

to see whether it is possible to send a notification based on the EPR from the replyTo field.

In the client code (JMS sender) I created a temporary queue for the replyTo field, and setup a receiver.

In the server I got the following:

21:40:04,937 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
21:40:04,937 INFO [STDOUT] Body: Hello World
21:40:04,937 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
21:40:04,937 WARN [ActionProcessingPipeline] Unexpected exception caught while
processing the action pipeline: header: [ To: JMSEpr [ PortReference < <wsa:Addr
ess jms://localhost/queue/hwreplytmp_esb/>, <wsa:ReferenceProperties jbossesb:ja
va.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:Refe
renceProperties jbossesb:java.naming.provider.url : jnp://127.0.0.1:1099/>, <wsa
:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jboss.naming:or
g.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>
, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:Referenc
eProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferencePro
perties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowle
dge-mode : 1/> > ] ReplyTo: JMSEpr [ PortReference < <wsa:Address jms://localhos
t/b-pyssdk9f-1-o3rsdk9f-evyubv-20o4c5/>, <wsa:ReferenceProperties jbossesb:desti
nation-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version :
1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory
/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferencePropert
ies jbossesb:acknowledge-mode : 1/>, <wsa:ReferenceProperties jbossesb:type : ur
n:jboss/esb/epr/type/jms/> > ] MessageID: ID:JBM-189940 RelatesTo: jms:correlati
onID#ID:JBM-190464 ]
org.jboss.soa.esb.actions.ActionProcessingException: Unexpected invocation targe
t exception from processor
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.process
Methods(ActionProcessorMethodInfo.java:127)
at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcesso
r.process(OverriddenActionLifecycleProcessor.java:74)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(
ActionProcessingPipeline.java:316)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$1.run(Messag
eAwareListener.java:303)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.IllegalArgumentException: 'jms://localhost/b-pyssdk9f-1-o3r
sdk9f-evyubv-20o4c5' is not a valid URI for a Logical EPR - URI scheme must be '
logical'.
at org.jboss.soa.esb.addressing.eprs.LogicalEPR.assertValidLogicalURI(Lo
gicalEPR.java:110)
at org.jboss.soa.esb.addressing.eprs.LogicalEPR.(LogicalEPR.java:5
5)
at org.jboss.soa.esb.addressing.eprs.LogicalEPR.(LogicalEPR.java:5
0)
at org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction.d
isplayMessage(MyJMSListenerAction.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.process
Methods(ActionProcessorMethodInfo.java:102)
... 6 more

On the client side, I first print the response message, and then check if it is an ObjectMessage and display the retrieved object.


[java] RESPONSE=delegator->JBossMessage[189941]:PERSISTENT, deliveryId=1
[java] Object:<?xml version="1.0" encoding="UTF-8"?>
[java]
[java] <Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/address
ing">
[java] <jbossesb:destination-type xmlns:jbossesb="http://schemas.jb
oss.com/ws/2007/01/jbossesb">queue</jbossesb:destination-type>
[java] <jbossesb:specification-version xmlns:jbossesb="http://schem
as.jboss.com/ws/2007/01/jbossesb">1.1</jbossesb:specification-version>
[java] <jbossesb:connection-factory xmlns:jbossesb="http://schemas.
jboss.com/ws/2007/01/jbossesb">ConnectionFactory</jbossesb:connection-factory>
[java] <jbossesb:persistent xmlns:jbossesb="http://schemas.jboss.co
m/ws/2007/01/jbossesb">true</jbossesb:persistent>
[java] <jbossesb:acknowledge-mode xmlns:jbossesb="http://schemas.jb
oss.com/ws/2007/01/jbossesb">1</jbossesb:acknowledge-mode>
[java] <jbossesb:type xmlns:jbossesb="http://schemas.jboss.com/ws/2
007/01/jbossesb">urn:jboss/esb/epr/type/jms</jbossesb:type>
[java] <wsa:To>jms://localhost/b-pyssdk9f-1-o3rsdk9f-evyubv-20o4c5<
/wsa:To>
[java] <wsa:From>
[java] <wsa:Address>jms://localhost/queue/hwreplytmp_esb</wsa:A
ddress>
[java] <wsa:ReferenceProperties>
[java] <jbossesb:java.naming.factory.initial xmlns:jbossesb
="http://schemas.jboss.com/ws/2007/01/jbossesb">org.jnp.interfaces.NamingContext
Factory</jbossesb:java.naming.factory.initial>
[java] <jbossesb:java.naming.provider.url xmlns:jbossesb="h
ttp://schemas.jboss.com/ws/2007/01/jbossesb">jnp://127.0.0.1:1099</jbossesb:java
.naming.provider.url>
[java] <jbossesb:java.naming.factory.url.pkgs xmlns:jbosses
b="http://schemas.jboss.com/ws/2007/01/jbossesb">org.jboss.naming:org.jnp.interf
aces</jbossesb:java.naming.factory.url.pkgs>
[java] <jbossesb:destination-type xmlns:jbossesb="http://sc
hemas.jboss.com/ws/2007/01/jbossesb">queue</jbossesb:destination-type>
[java] <jbossesb:specification-version xmlns:jbossesb="http
://schemas.jboss.com/ws/2007/01/jbossesb">1.1</jbossesb:specification-version>
[java] <jbossesb:connection-factory xmlns:jbossesb="http://
schemas.jboss.com/ws/2007/01/jbossesb">ConnectionFactory</jbossesb:connection-fa
ctory>
[java] <jbossesb:persistent xmlns:jbossesb="http://schemas.
jboss.com/ws/2007/01/jbossesb">true</jbossesb:persistent>
[java] <jbossesb:acknowledge-mode xmlns:jbossesb="http://sc
hemas.jboss.com/ws/2007/01/jbossesb">1</jbossesb:acknowledge-mode>
[java] <jbossesb:type xmlns:jbossesb="http://schemas.jboss.
com/ws/2007/01/jbossesb">urn:jboss/esb/epr/type/jms</jbossesb:type>
[java] </wsa:ReferenceProperties>
[java] </wsa:From>
[java] <wsa:RelatesTo>ID:JBM-189940</wsa:RelatesTo>
[java] <wsa:MessageID>a79e2900-5de7-48ee-93f4-a807b2abcaa2</wsa:Mes
sageID>
[java]
[java]
[java]
[java]
[java] <![CDATA[b3JnLmpib3NzLnNvYS5lc2IubWVzc2FnZS5mYXVsdC
50aHJvd2FibGU=]]>
[java]
[java]
[java] <plugin-type>urn:xml/marshalunmarshal/plugin/ser
ialization</plugin-type><![CDATA[rO0ABXNyADNvcmcuamJvc3Muc29hLmVzYi5hY3Rpb25zLkF
jdGlvblByb2Nlc3NpbmdFeGNlcHRp
[java] b24AAAAAAAAAAQIAAHhyAB9vcmcuamJvc3Muc29hLmVzYi5CYXNlRXhjZXB0aW9uAAAA
AAAAAAEC

.... truncated ....

[java] AH4ANnEAfgA3cQB+ADhzcQB+AA4AAAKjcQB+ADZxAH4AN3EAfgA0c3EAfgAOAAACU3EA
fgA7cQB+
[java] ADxxAH4ANHg=]]>
[java]
[java]
[java]
[java] <![CDATA[b3JnLmpib3NzLnNvYS5lc2IubWVzc2FnZS5mYXVsdC
5yZWFzb24=]]>
[java]
[java]
[java] <plugin-type>urn:xml/marshalunmarshal/plugin/ser
ialization</plugin-type><![CDATA[rO0ABXQAam9yZy5qYm9zcy5zb2EuZXNiLmFjdGlvbnMuQWN
0aW9uUHJvY2Vzc2luZ0V4Y2VwdGlv
[java] bjogVW5leHBlY3RlZCBpbnZvY2F0aW9uIHRhcmdldCBleGNlcHRpb24gZnJvbSBwcm9j
ZXNzb3I=]]>
[java]
[java]
[java]
[java] <![CDATA[b3JnLmpib3NzLnNvYS5lc2IubWVzc2FnZS5mYXVsdC
5jb2Rl]]>
[java]
[java]
[java] <plugin-type>urn:xml/marshalunmarshal/plugin/ser
ialization</plugin-type><![CDATA[rO0ABXNyAAxqYXZhLm5ldC5VUkmsAXguQ55JqwMAAUwABnN
0cmluZ3QAEkxqYXZhL2xhbmcvU3Ry
[java] aW5nO3hwdAAgdXJuOmFjdGlvbi9lcnJvci91bmV4cGVjdGVkZXJyb3J4]]></marshal
unmarshal>
[java]
[java]
[java]
[java]
[java]
[java] <![CDATA[b3JnLmpib3NzLnNvYS5lc2IubWVzc2FnZS50aW1lLm
RvYg==]]>
[java] <![CDATA[rO0ABXQAHFdlZCBOb3YgMjggMjE6NDA6MDQgR01U
IDIwMDc=]]>
[java]
[java]
[java] <![CDATA[b3JnLmpib3NzLnNvYS5lc2IubWVzc2FnZS5zb3VyY2
U=]]>
[java] <![CDATA[rO0ABXQARVBvcnRSZWZlcmVuY2UgPCBqbXM6Ly9s
b2NhbGhvc3QvYi1weXNzZGs5Zi0xLW8zcnNk
[java] azlmLWV2eXVidi0yMG80YzUgPg==]]>
[java]
[java]
[java] <![CDATA[b3JnLmpib3NzLnNvYS5lc2IubWVzc2FnZS50cmFuc3
BvcnQudHlwZQ==]]>
[java] <![CDATA[rO0ABX5yAC9vcmcuamJvc3Muc29hLmVzYi5jb21t
b24uRW52aXJvbm1lbnQkVHJhbnNwb3J0cwAA
[java] AAAAAAAAEgAAeHIADmphdmEubGFuZy5FbnVtAAAAAAAAAAASAAB4cHQAA0pNUw==]]><
/Value>
[java]
[java]
[java]
[java]

So, although the server throws an exception, the message is actually sent to the temporary queue - however it is received in this structured but unmarshalled format.

This reminded me that when I did a request/response test, using a JMS client (with temp replyTo queue), I also got a response in this format - i.e. not the unmarshalled message, and this was using the standard request/response approach where the response is returned from the action (unlike in ths above test where it is explicitly sent using 'deliverAsync').

Sorry for the long post, but hopefully it provides the necesary info. If you want, I can package up the modified helloworld example.

Regards
Gary

[objectiser]

Based on the information in the previous post:

1) Would it be possible to have an additional ServiceInvoker constructor that could take any EPR implementation - so instead of doing a ServiceRegistry lookup to get the EPR, it is provided explicitly. This would then remove the need to use the LogicalEPR, and therefore the complaint about the URI format.

2) I think I undrstand why the message is being received in the format shown in the previous post, and why in my req/resp test I was having the same problem. Normally if a message is being sent from a JMS client to an ESB service, it would go through a gateway to convert the message - hence the two destinations (_gw and _esb in the examples).

However, if the client adds a replyTo temporary queue to the message, it appears as if the service is returning its message directly to that temporary queue - it is not going via a gateway to unmarhall the message.

Is this supposed to happen? Am I missing some configuration to ensure this occurs.

3) If I define a permanent queue in the same situation (e.g. myResponse_gw), how do I ensure that this gets translated into another permanent queue (e.g. myResponse_esb) that is passed to the service? Do these queues normally have to be registered against a service configuration to establish the coupling between them?

[tfennelly]

Maaaan... you do like long posts ;-) Now for my long response....

wrt getting the serialized/marshalled form of the message on the receiver side after using the ServiceInvoker to send.... that's because the ESB Registry (and so the ServiceInvoker) assume the receiver to be "message aware". So, if that JMS queue was registered through the jms-listener (i.e. managed by the ESB) and the code processing that message was in an ESB Action... that action would receive the message deserialized/unmarshalled. Otherwise... you can use the Util.deserialize (excuse the class naming) message on the serialized message form.

Maybe you understand this from #2 in your last post, but one thing to clarify... Gatways don't unmarshall anything. Gateways are used to get messages onto the bus i.e. to normailze them into the ESB Message structure before they're exchanged between "message aware" components on the bus (actions, message aware listeners etc).

wrt the ServiceInvoker taking an EPR.... uuuuh.... not sure I like the sound of that! With the exception of the LogicalEPR... we're actually trying to hide EPRs as much as possible, so we'd need major convincing re changing one of the most public parts of the ESB API in this way. Lets see can we explore other alternatives... e.g. why must it be a temp queue?? ... why not have the ESB manage that endpoint too??

[objectiser]

Ok, understand about hiding the EPR - then its possibly just a case of enabling the LogicalEPR to deal with the port reference details for other EPR implementations - which it appears to do, but throws an exception at the same time.

The reason for using the temp queue is that it is a native JMS client, and wishes to ensure its response is sent to a unique queue - it has no knowledge of the ESB, so Util.deserialize would not be an option.

So I guess my third question still stands - how would a pure JMS client (i.e. outside the ESB), whether using a temp or permanent queue, supply it as a replyTo destination and get back a deserialized message?

[tfennelly]

"objectiser" wrote:
Ok, understand about hiding the EPR - then its possibly just a case of enabling the LogicalEPR to deal with the port reference details for other EPR implementations - which it appears to do, but throws an exception at the same time.

Not sure what you mean by getting the LogicalEPR to deal with port ref's for other EPR impls.

"objectiser" wrote:
The reason for using the temp queue is that it is a native JMS client, and wishes to ensure its response is sent to a unique queue - it has no knowledge of the ESB, so Util.deserialize would not be an option.

So I guess my third question still stands - how would a pure JMS client (i.e. outside the ESB), whether using a temp or permanent queue, supply it as a replyTo destination and get back a deserialized message?

If you want you're external calling service/client to be completely unaware of the fact that it's integrating to the backend service via the ESB, then yes, you need to come through a gateway (jms-listener in this case).

So, what you could do is independently define your JMS message structure on the client side, setting the reply-to temp queue name in that. Then within the ESB, you can define your own "MessageComposer" class on the jms-listener that receives this message, such that the reply-to is extracted from the incoming JMS message and put onto the normalized form created by the composer. In fact, I'd be surprised if this isn't already happening for you.

On the way back... you could try using the JMSRouter class to route back to the temp queue named in the incoming message. That class extends "AbstractRouter", which supports an "unwrap" property i.e. deserialize the message before routing it.

[objectiser]

I need to do some experimenting with your suggested approach - but just to answer the first part, at the moment it is possible for a service to supply its preferred replyto EPR using the LogicalEPR, which would enable the destination service to delay responding (i.e. send a notification sometime after the request pipeline has been completed).

However it would be nice to achieve the same with pattern where the replyTo address is not a LogicalEPR, but a JMSEpr or a web service address.

From my previous experiment, it appears that the LogicalEPR can be initialised with the PortReference from these other EPR implementations, and subsequently used by the ServiceInvoker obtained from the LogicalEPR.

Now whether the LogicalEPR should support this functionality, or whether another LogicalEPR type EPR implementation should be created to handle this capability, it would be your choice - but I think this functionality would be a useful addition to the product. Otherwise there is no means to do a delayed response (or notification) to any other service other than another JBoss ESB service (using the LogicalEPR).

[objectiser]

Hi Tom

Had a look at the JMSRouter and it appears as if the service configuration needs to nominate the destination queue - so would not work as the destination would be unknown as it is supplied by the runtime (whether permanent or temporary queue).

Would it not be possible for the inbound message gateway, which must take the replyTo destination and convert it into a JMSEpr, to flag the EPR as being for a message 'unaware' destination, so that when the outbound notification (or response) is being sent to that EPR, it could automatically unwrap the message?

This would simplify the service configuration in a simple req/resp scenario, and would make the service configuration suitable for both message aware, and message unaware clients. If something specific has to be inserted into the pipeline to unwrap the message, then this would make the service configuration specific for message unaware clients.

At the moment I can't see how to do a req/resp from a native JMS client to an ESB service, to get an unwrapped response back.

Regards
Gary

[tfennelly]

Hey Gary, you working from a distro or from source (http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/). It wouldn't be difficult at all to change the AbstractRouter impl to check the Message for a destination type property of some sort, doing the unwrap based on that.

Long term, I think it's planned (I hope) to allow EPR registrations to be decorated with additional info re the endpoint capabilities. I logged a JIRA for this back in April of this year: JBESB-498.

[objectiser]

Hi Tom, I'm currently using 4.2.1GA.

I think I will initially concentrate on just message aware service to service interactions, as I think using the LogicalEPR works fine for what I need.

Thanks for your help.
Regards
Gary