Hi Asankha,
The patch attached to AXIS2-1488 seems to be partial - just applying it over
the 1.1.1 code does not work. That probably explains why Deepal did not check
it in as is in the main trunk.
However, I built axis2.war from the main branch and the JMSListener is working
when deployed on JBoss. As I mentioned previously I am just trying out the
quickstart sample to see how this works.
I generated a stub based on the wsdl that the service generates and published a
message to the queue using the stub. So far so good. However, the service is
failing to dispatch the message with the following error:
...
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.
Any ideas regarding what am I missing here?
Thanks
Shantanu
----- Original Message ----
From: Asankha C. Perera <[EMAIL PROTECTED]>
To: [email protected]
Sent: Saturday, March 17, 2007 1:59:59 AM
Subject: Re: Axis2: soap/jms question
Hi Shantanu
> I have followed the JMS transport doc
> (http://people.apache.org/~thilina/axis2/docs/jms-transport.html) and
> modified the services.xml of the stockquoteservice as follows
>
Ok, I guess its the same as the official doc found at
http://ws.apache.org/axis2/1_1/jms-transport.html
> ====
> ...
> <transports>
> <transport>jms</transport>
> </transports>
>
> <messageReceivers>
>
>
> class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
>
>
> class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
> </messageReceivers>
> http://quickstart.samples/xsd"/>
> <parameter
> name="ServiceClass">samples.quickstart.service.pojo.StockQuoteService</parameter>
> <parameter name="transport.jms.Destination"
> locked="true">queue/requestQ</parameter>
> <parameter name="transport.jms.ConnectionFactory"
> locked="true">QueueConnectionFactory</parameter>
> ...
> ====
>
> I have also modified axis2.xml with the relevant JBoss configurations:
>
> ===
> ...
> <transportReceiver name="jms"
> class="org.apache.axis2.transport.jms.JMSListener">
> <parameter name="myQueueConnectionFactory" locked="false">
>
> <parameter name="java.naming.factory.initial"
> locked="false">org.jnp.interfaces.NamingContextFactory</parameter>
> <parameter name="java.naming.provider.url"
> locked="false">jnp://localhost:1099</parameter>
> <parameter name="transport.jms.ConnectionFactoryJNDIName"
> locked="false">ConnectionFactory</parameter>
> </parameter>
> ..
> ===
>
The above is incorrect, for the service you are asking it to use the
connection factory definition of Axis2 under the name
"myQueueConnectionFactory" but the entry name specified under Axis2 is
"ConnectionFactory".
> Firstly, once I deployed this I did not see any indication that the
> JMSListener has been started. I saw that there was an issue with starting of
> non-http transports for the embedded axis as described in
> https://issues.apache.org/jira/browse/AXIS2-1488, which is now resolved. Did
> this fix make it's way to the 1.1.1 version?
>
Not sure, as the fix version is not specified in the bug entry when it
was closed :-(
> If the above bug is still not resolved in the 1.1.1 version, are there any
> workarounds to start the JMSListener for an embedded axis2 instance?
>
If you downloaded the source distribution or applied the patch attached
to the JIRA to the code and rebuild that may be a solution...
> Secondly, once I deployed the service (stockquoteservice.aar), I obtained a
> strange WSDL from
> http://localhost:8080/axis2/services/StockQuoteService?wsdl. A part of the
> WSDL is shown below. Note that the transport is still http and the service
> ports are not generated. Note that in the services.xml I have specifically
> mentioned only the jms transport. So, why are the soap bindings still
> generated in the wsdl? Looks like a bug to me.
Since JMS configuration was incorrect and the transport didn't start in
your environment, I suggest that you look at this issue once those are
fixed, as then this may also work
asankha
>
>
> ===
> <wsdl:binding name="StockQuoteServiceHttpBinding"
> type="axis2:StockQuoteServicePortType">
> <http:binding verb="POST" />
> - <wsdl:operation name="update">
> <http:operation location="update" />
> + <wsdl:input>
> <mime:content type="text/xml" />
> </wsdl:input>
> </wsdl:operation>
> - <wsdl:operation name="getPrice">
> <http:operation location="getPrice" />
> - <wsdl:input>
> <mime:content type="text/xml" />
> </wsdl:input>
> - <wsdl:output>
> <mime:content type="text/xml" />
> </wsdl:output>
> </wsdl:operation>
> </wsdl:binding>
> <wsdl:service name="StockQuoteService" />
> </wsdl:definitions>
> ====
>
> Thirdly, the WSDL that the jms client will be using - do we need to generate
> is manually? I understand the jms destination URLwill need to be added
> manually to the stub, but I was hoping to get a partial WSDL generated. When
> I try to do a wsdl2java on the generated wsdl from the above service, it
> throws an NPE.
>
> Any pointers regarding the basic steps of running soap/jms on an embedded
> axis2 installation will be of great help.
>
If I can remember, I think someone posted some information on this to
the mailing lists some time back .. maybe you could search the
archives.. else the solution is to write or update the code to start the
JMS transport
> Thanks,
> Shantanu Sen
>
>
>
> ---------------------------------------------------------------------
> 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]
