axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Chinthaka Suriarachchi (JIRA)" <>
Subject [jira] Commented: (AXIS2-4729) URI based dispatching is too tightly coupled to the HTTP transport
Date Mon, 31 May 2010 05:41:36 GMT


Amila Chinthaka Suriarachchi commented on AXIS2-4729:

I thought, axis2 uses servicePath as a delimiter of service/operation part.

i.e for any uri it can search for 'services' (or as given in axis2.xml) and find the service/operation

But as you have given it combines this with context root. Further thinking in the way you
have given, these properties should belongs to transport parameters rather than axis2.xml
top level parameters.

What I would like to suggest is to do what I was thinking :)

use service part as a delimiter. Then is is transport independent and any one can have any
thing before it.

e.g. http://localhost:8080/axis2/services/Myservice

> URI based dispatching is too tightly coupled to the HTTP transport
> ------------------------------------------------------------------
>                 Key: AXIS2-4729
>                 URL:
>             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:
> <scheme>://<host>:<port>/<serviceContextPath>/<serviceName>...
> 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:
> (udp|tcp)://<host>:<port>/<serviceName>...
> What this shows is that:
> * The current URI based dispatching mechanism in Axis2 is too tightly coupled to the
HTTP protocol.
> * 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

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