axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Created: (AXIS2-4729) URI based dispatching is too tightly coupled to the HTTP transport
Date Sun, 30 May 2010 12:56:36 GMT
URI based dispatching is too tightly coupled to the HTTP transport

                 Key: AXIS2-4729
             Project: Axis2
          Issue Type: Bug
          Components: kernel
            Reporter: Andreas Veithen

URI based dispatching is supported for all transports that define an EPR syntax that uses
hierarchical URIs (in the sense of RFC3986) and where the path component of the EPR is not
used for transport specific information:

HTTP: Uses hierarchical URIs and the path information is exchanged as part of the HTTP request
-> URI based dispatching is always possible.
Mail: Uses the "mailto:" scheme, which is not hierarchical -> no URI based dispatching.
JMS: Uses hierarchical URIs, but the path component of the EPR identifies the JMS destination
-> no URI based dispatching.
UDP & TCP: Use hierarchical URIs, but they are not used by the transport protocol itself
-> URI based dispatching is possible if WS-Addressing is used.

For dispatching, Axis2 assumes that the EPRs have the following form:


serviceContextPath corresponds to the property with the same name in ConfigurationContext
and is built from the contextRoot and servicePath parameters in axis2.xml. These two parameters
take into the fact that a Web application

* has a context root;
* may have additional servlets other than AxisServlet (e.g. the admin console in the default
Axis2 web app) and that therefore, the url-pattern of AxisServlet is not necessarily "/*"
(it is "/services/*" in the default web app).

It is clear that this is only meaningful for the HTTP transport. There may be other transport
protocols for which the concept of a "service context path" makes sense, but there is currently
no example for this. For the UDP and TCP transports, this concept is meaningless and one would
expect that EPRs for these protocols simply have the following form:


What this shows is that:

* The current URI based dispatching mechanism in Axis2 is too tightly coupled to the HTTP
* It makes the assumption that the serviceContextPath is the same for all transports deployed
in a given Axis2 instance. This is incorrect.

There are several potential solutions for this problem:

1. Introduce additional transport specific dispatchers that handle the case of transports
without serviceContextPath. Note that in most cases these dispatchers would have to act as
replacements for AddressingBasedDispatcher (because the URI based dispatching is done at the
WS-Addressing level). Problem: doesn't solve the root cause and introduces additional complexity
(the user needs to configure these additional dispatchers to make the transport work correctly).

2. Introduce a new MessageContext property that the TransportListener may set to specify the
serviceContextPath applicable to the transport. This property would then be used by RequestURIBasedServiceDispatcher
and AddressingBasedDispatcher during dispatching. Problem: this only works if the EPR used
for dispatching belongs to the incoming transport. This may not be the case with WS-Addressing:
e.g. it is possible to specify an HTTP EPR in a WS-A header of a message sent over another

3. Define an extension interface that would be implemented by TransportListeners that use
hierarchical EPRs. This interface would be used by RequestURIBasedServiceDispatcher and AddressingBasedDispatcher
to query the serviceContextPath applicable to a given transport protocol.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message