Re: Axis2: soap/jms question

Sat, 24 Mar 2007 10:59:03 -0800

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: [email protected]
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&amp;java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory&amp;java.naming.provider.url=""
        <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]

Reply via email to