Asankha,
I pulled the code from the trunk yesterday and now jms binding is working fine
on jboss. Thanks for the fix.
Two questions:
1. Is there a way to specify the temporary queue jndi name for blocking calls
using the jms transport?
2. For non-blocking two way operations how can we specify that the response
should be published to a separate queue? I did not try this, but if I set the
wsa:replyTo from the client, with a jms specific url that specifies the
response queue jndi name, will the service pick this up from the wsa:replyTo
and publish the response to this queue using the specified url?
Thanks,
Shantanu
----- Original Message ----
From: Asankha C. Perera <[EMAIL PROTECTED]>
To: axis-user@ws.apache.org
Sent: Saturday, March 24, 2007 11:58:33 AM
Subject: Re: Axis2: soap/jms question
Shantanu / John Turner
I have reapplied the fixes for 2030 and 2277 and fixed the unit tests,
as I had to revert them last week due to test failures. Would be great
if you could verify this with JBoss or other implementations. The
changes are all in the o.a.a.transport.jms package (3 files)
asankha
Shantanu Sen wrote:
Hi Asankha,
Sounds good. Please let me know the specific file that you patch so that I do
not have to update the whole tree again.
Thanks,
Shantanu
----- Original Message ----
From: Asankha C. Perera <[EMAIL PROTECTED]>
To: axis-user@ws.apache.org
Sent: Thursday, March 22, 2007 9:54:49 PM
Subject: Re: Axis2: soap/jms question
Hi Shantanu
17:12:30,812 ERROR [JMSMessageReceiver] JMS Worker [JMSWorker-1]
Encountered an
Axis Fault : The [action] cannot be processed at the receiver.
org.apache.axis2.AxisFault: The [action] cannot be processed at the receiver.
at org.apache.axis2.addressing.AddressingFaultsHelper.triggerAddressingF
ault(AddressingFaultsHelper.java:346)
at org.apache.axis2.addressing.AddressingFaultsHelper.triggerActionNotSu
pportedFault(AddressingFaultsHelper.java:311)
at org.apache.axis2.handlers.addressing.AddressingValidationHandler.chec
kAction(AddressingValidationHandler.java:137)
at org.apache.axis2.handlers.addressing.AddressingValidationHandler.invo
ke(AddressingValidationHandler.java:50)
at org.apache.axis2.engine.Phase.invoke(Phase.java:383)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:203)
...
On investigating, it seems that the AddressValidationHandler.checkAction will
always throw this exception as the following code indicated if the operation
and service values are null.
---
if ((msgContext.getAxisService() == null) || (msgContext.getAxisOperation()
== null)) {
AddressingFaultsHelper
.triggerActionNotSupportedFault(msgContext,
msgContext.getWSAAction());
}
----
Now here is the envelope that is generated by the stub and published in the JMS
message:
---
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Header>
<wsa:To>jms:/queue/requestQ?transport.jms.ConnectionFactoryJNDIName=ConnectionFactory&java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory&java.naming.provider.url=jnp://localhost:1099</wsa:To>
<wsa:ReplyTo>
http://www.w3.org/2005/08/addressing/anonymous
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:6EE9E1632283F7F99D1174613253567</wsa:MessageID>
<wsa:Action>urn:getPrice</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<ns1:symbol>MSFT</ns1:symbol>
</ns1:getPrice>
</soapenv:Body>
</soapenv:Envelope>
--
I also noted that previous to invoking the handlers in the dispatch phase (i.e.
in the pre-dispatch phase), the AddressingInHandler successfully parses the
wsa:Action info from the soap headers. Should'nt this be responsible for
setting the operation (getPrice) in this case?
I tried to find out why the messageContext was not getting filled with the
serviceName. It seems that in JMSMessageReceiver.createMessageContext, it looks
for the servicename based on the destinationName as shown in the following code:
--
Destination dest = message.getJMSDestination();
String destinationName = null;
if (dest instanceof Queue) {
destinationName = ((Queue) dest).getQueueName();
} else if (dest instanceof Topic) {
destinationName = ((Topic) dest).getTopicName();
}
String serviceName =
jmsConFac.getServiceNameForDestination(destinationName);
---
However, the destination name in this case (JBOSS MQ) is 'requestQ'. Note that
the services.xml contains the following as the parameter:
<parameter name="transport.jms.Destination"
locked="true">queue/requestQ</parameter>
And the JMSConnectionFactory stores the mapping as follows in the destinations
variable:
{queue/requestQ=StockQuoteService}
Hence the serviceName is returned as null since JBOSS returns requestQ and not
queue/requestQ as the destination name.
You are spot on correct in your analysis, and earlier this week I
committed a patch that would fix the above, but unfortunately had to
revert it back due to unit test failures as I didn't have time to
investigate it due to commitments on Apache Synapse. I will promise to
commit this patch with proper testing over this weekend and I think you
could test it early next week and give me first hand feedback
asankha
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
