[
https://issues.apache.org/jira/browse/AXIS2-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873550#action_12873550
]
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 part.
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
tcp://localhost:6060/services/Myservic
> URI based dispatching is too tightly coupled to the HTTP transport
> ------------------------------------------------------------------
>
> Key: AXIS2-4729
> URL: https://issues.apache.org/jira/browse/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:
> <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 transport.
> 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: [email protected]
For additional commands, e-mail: [email protected]
