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=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]

Reply via email to