You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Steve Loughran <st...@apache.org> on 2005/11/15 12:41:38 UTC
[Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
I've just got my code moved up to SVN head, and things are not
dispatching right. I've been looking through the tracelogs and here are
some issues to raise
1. In the response to an operation, the reply to address contains
seemingly gratuitous ServiceGroup reference parameters. Why?
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">Create</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
<wsa:ReferenceParameters>
<axis2:ServiceGroupId
xmlns:axis2="http://ws.apache.org/namespaces/axis2">FC7E73DE89044C7353113205436946441</axis2:ServiceGroupId>
</wsa:ReferenceParameters>
</wsa:ReplyTo>
<wsa:From
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://127.0.0.1:8081/services/Portal</wsa:Address>
</wsa:From>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">FC7E73DE89044C7353113205436946442</wsa:MessageID>
<wsa:RelatesTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
wsa:RelationshipType="wsa:Reply">uuid:EC4C79FF4A1D2655AE11320543690431</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body>
<ns:createResponse
xmlns:ns="http://www.gridforum.org/cddlm/deployapi/2005/02">
<ns:ResourceId>uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82</ns:ResourceId>
<ns:systemReference>
<add:Address
xmlns:add="http://schemas.xmlsoap.org/ws/2003/03/addressing">http://localhost:8081/services/System/?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82</add:Address>
</ns:systemReference>
</ns:createResponse>
</soapenv:Body>
</soapenv:Envelope>
2. Addresses with ?name=value parts are not handled properly in the POST
header or dispatch.
(a) the ?name=value bit of the URL is duplicated in the POST.
(b) dispatch should be based on the path of the URL, not the ?params,
which are parameters.
POST
/services/System/?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82
HTTP/1.1
User-Agent: Axis/2.0
Connection: Keep-Alive
Host: 127.0.0.1:8081
Content-Length: 1541
Content-Type: application/soap+xml; charset=UTF-8;action="Terminate";
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://localhost:8081/services/System/?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">Terminate</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543702332</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://localhost:8081/services/System/?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">Terminate</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543702332</wsa:MessageID>
</soapenv:Header>
<soapenv:Body>
<api:terminateRequest
xmlns:api="http://www.gridforum.org/cddlm/deployapi/2005/02">
<api:reason>requested termination</api:reason>
</api:terminateRequest>
</soapenv:Body>
</soapenv:Envelope>
This message fails with an error that there is no service with that name
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header></soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>Sender</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text>Service Not found EPR is
http://localhost:8081/services/System/?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82</soapenv:Text>
</soapenv:Reason>
<soapenv:Node>http://myAxisServer/role/default</soapenv:Node>
<soapenv:Role>http://myAxisServer/role/default</soapenv:Role>
<soapenv:Detail>
<soapenv:Exception>org.apache.axis2.AxisFault: Service
Not found EPR is
http://localhost:8081/services/System/?system=uuid_8fe54e9c_e246_4939_a5ae_2c96566d5d82
at
org.apache.axis2.engine.DispatchingChecker.invoke(DispatchingChecker.java:66)
at org.apache.axis2.engine.Phase.invoke(Phase.java:165) at
org.apache.axis2.engine.AxisEngine.invokePhases(AxisEngine.java:447)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:144) at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:212)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:180) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at
org.mortbay.jetty.servlet.ServletHandler.dispatch(ServletHandler.java:657)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at
org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at
org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at
org.mortbay.http.HttpServer.service(HttpServer.java:879) at
org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520)</soapenv:Exception>
</soapenv:Detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
3. Messages sent out on an existing call show uncontrolled header bloat.
this may be my code doing this, I am not sure. I just see lots of
reptition of values on anything that has been used for a call already.
POST /services/Portal HTTP/1.1
User-Agent: Axis/2.0
Connection: Keep-Alive
Host: 127.0.0.1:8081
Content-Length: 4562
Content-Type: application/soap+xml; charset=UTF-8;action="LookupSystem";
<?xml version="1.0" encoding="UTF-8" ?>
<soapenv:Envelope
xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
<wsa:To
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">http://127.0.0.1:8081/services/Portal</wsa:To>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">LookupSystem</wsa:Action>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:EC4C79FF4A1D2655AE11320543737215</wsa:MessageID>
</soapenv:Header>
<soapenv:Body>
<ns:lookupSystemRequest
xmlns:ns="http://www.gridforum.org/cddlm/deployapi/2005/02">
<ns:ResourceId>Unknown</ns:ResourceId>
</ns:lookupSystemRequest>
</soapenv:Body>
</soapenv:Envelope>
Because of (#2), I dont have a functional system. the other two are just
bits that worry me.
-steve
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Davanum Srinivas <da...@gmail.com>.
Eran,
my 2 cents, the ServiceGroupContext RefP stuff should not be on by
default. If it is then there should be a way to switch it off as well.
thanks,
dims
On 11/15/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> Steve,
>
> Let me answer the first question (only ;-) )
>
> Steve Loughran wrote:
>
> >
> > I've just got my code moved up to SVN head, and things are not
> > dispatching right. I've been looking through the tracelogs and here
> > are some issues to raise
> >
> >
> > 1. In the response to an operation, the reply to address contains
> > seemingly gratuitous ServiceGroup reference parameters. Why?
> >
> Well, each and every service group context we create within the
> AxisEngine has a unique id. We send that back to the client. So if the
> client wants to maintain the same service group for his next
> invocations, he should send that back to the server as a header parameters.
> Its a convenience way of maintaing the service group session
>
> There is a ServiceGroupContextTest and Chamikara wrote a nice sample
> using that, please look in to that.
>
> Are you saying this id is "seemingly gratuitous", because you don't know
> what service group context id or you have some other good reason ?
>
> - Chinthaka
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-11-15 at 14:52 +0000, Steve Loughran wrote:
> well, it's seemingly gratuitous because it exposes an implementation
> detail (axis2) and a concept (sessions), that I dont want.
Good point. We clearly need to be able to allow this .. and I guess it
should come into being if the service has scope = session only. IIRC we
haven't done that part yet .. so as soon as we do it we can make this
configurable.
Even in that case I think we can set up an option to tie a session to an
HTTP session, which is not as good as a SOAP session but it may be good
enough for the user's scenario.
Sanjiva.
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Steve Loughran <st...@apache.org>.
Eran Chinthaka wrote:
> Steve,
>
> Let me answer the first question (only ;-) )
>
> Steve Loughran wrote:
>
>
>>I've just got my code moved up to SVN head, and things are not
>>dispatching right. I've been looking through the tracelogs and here
>>are some issues to raise
>>
>>
>>1. In the response to an operation, the reply to address contains
>>seemingly gratuitous ServiceGroup reference parameters. Why?
>>
>
> Well, each and every service group context we create within the
> AxisEngine has a unique id. We send that back to the client. So if the
> client wants to maintain the same service group for his next
> invocations, he should send that back to the server as a header parameters.
> Its a convenience way of maintaing the service group session
>
> There is a ServiceGroupContextTest and Chamikara wrote a nice sample
> using that, please look in to that.
>
> Are you saying this id is "seemingly gratuitous", because you don't know
> what service group context id or you have some other good reason ?
>
> - Chinthaka
>
well, it's seemingly gratuitous because it exposes an implementation
detail (axis2) and a concept (sessions), that I dont want.
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Srinath Perera <he...@gmail.com>.
> I don't think its a good idea to use RM's sequence ID header because
> it'll conflict when echoing back: reference params become regular
> headers and then you could end up with two RM sequence ID headers, which
> would be a bit ugly. (Even if it can be made to work .. with the W3C
> versions of WS-Addr reference params are marked, so it is possible to
> make it work.)
What I had in mind is since sequnce is not something special to RM or
Secure conversation ect .. The Sequnce should be handled by Axis2
rather than each handler. That enables users to use sequence without
RM ect. (We can tie it to Service/ServiceGroup context and provide
life cycle and grouping support as well)
But I agree if we put it as a referance parameter and that end has RM,
the Headers will be in conflict! But that is a standard problem I
think .. I hope Addressing spec says what should be done in that case
:)
But it might get too complex to handle right now .. lets get the thing
working with our own header and look in to that possiblity later
Srinath
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-11-15 at 09:42 -0500, Srinath Perera wrote:
> Hi Eran,Steve;
>
> I am +1 for adding a referance parameter as that provide a way to use
> the hierachy provided by the Axis2 to it's real ability. I have two
> sugessions
>
> 1) If possible use something standarized, e.g. sequnce ID from the RM
> spec rather than sending axis2 header. I think it is good Idea to let
> users keep a sequnce even though they do not use RM or secure
> conversion. My be we do not have something 1-1 with it. We have define
> *something* to be 1-1 with it.
But this is *precisely* the design of reference parameters: stuff that
the originator of the EPR wants echoed back. These are basically the
cookies of the SOAP world ..
I don't think its a good idea to use RM's sequence ID header because
it'll conflict when echoing back: reference params become regular
headers and then you could end up with two RM sequence ID headers, which
would be a bit ugly. (Even if it can be made to work .. with the W3C
versions of WS-Addr reference params are marked, so it is possible to
make it work.)
> 2) Make this bahvaior optional , provide configuration option to turn this off
+1; as I said in my reply to Steve, we need this iff scope=session is in
use on the server side. Even in that case we can allow the user to use
the HTTP session ID cookie for the HTTP case if that's what they want.
Sanjiva.
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Srinath Perera <he...@gmail.com>.
Hi Eran,Steve;
I am +1 for adding a referance parameter as that provide a way to use
the hierachy provided by the Axis2 to it's real ability. I have two
sugessions
1) If possible use something standarized, e.g. sequnce ID from the RM
spec rather than sending axis2 header. I think it is good Idea to let
users keep a sequnce even though they do not use RM or secure
conversion. My be we do not have something 1-1 with it. We have define
*something* to be 1-1 with it.
2) Make this bahvaior optional , provide configuration option to turn this off
Thanks
Srinath
On 11/15/05, Eran Chinthaka <ch...@opensource.lk> wrote:
> Steve,
>
> Let me answer the first question (only ;-) )
>
> Steve Loughran wrote:
>
> >
> > I've just got my code moved up to SVN head, and things are not
> > dispatching right. I've been looking through the tracelogs and here
> > are some issues to raise
> >
> >
> > 1. In the response to an operation, the reply to address contains
> > seemingly gratuitous ServiceGroup reference parameters. Why?
> >
> Well, each and every service group context we create within the
> AxisEngine has a unique id. We send that back to the client. So if the
> client wants to maintain the same service group for his next
> invocations, he should send that back to the server as a header parameters.
> Its a convenience way of maintaing the service group session
>
> There is a ServiceGroupContextTest and Chamikara wrote a nice sample
> using that, please look in to that.
>
> Are you saying this id is "seemingly gratuitous", because you don't know
> what service group context id or you have some other good reason ?
>
> - Chinthaka
>
>
Re: [Axis2] dispatch and addressing issues w/ SVN_HEAD axis2
Posted by Eran Chinthaka <ch...@opensource.lk>.
Steve,
Let me answer the first question (only ;-) )
Steve Loughran wrote:
>
> I've just got my code moved up to SVN head, and things are not
> dispatching right. I've been looking through the tracelogs and here
> are some issues to raise
>
>
> 1. In the response to an operation, the reply to address contains
> seemingly gratuitous ServiceGroup reference parameters. Why?
>
Well, each and every service group context we create within the
AxisEngine has a unique id. We send that back to the client. So if the
client wants to maintain the same service group for his next
invocations, he should send that back to the server as a header parameters.
Its a convenience way of maintaing the service group session
There is a ServiceGroupContextTest and Chamikara wrote a nice sample
using that, please look in to that.
Are you saying this id is "seemingly gratuitous", because you don't know
what service group context id or you have some other good reason ?
- Chinthaka
Re: [Axis2] dispatch of path?query valies
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me as well.
-- dims
On 11/15/05, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Tue, 2005-11-15 at 15:41 +0000, Steve Loughran wrote:
> >
> > Now, what part of RFC2616 is Axis2's URL handling exempt from? Unless I
> > hear a good reason wny ?
>
> :)
>
> > params should be intermittently used for
> > dispatching, I am going to tweak dispatch so that ? strings are always
> > dropped on the floor.
>
> +1 .. please go ahead and fix it!
>
> Sanjiva.
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: [Axis2] dispatch of path?query valies
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Tue, 2005-11-15 at 15:41 +0000, Steve Loughran wrote:
>
> Now, what part of RFC2616 is Axis2's URL handling exempt from? Unless I
> hear a good reason wny ?
:)
> params should be intermittently used for
> dispatching, I am going to tweak dispatch so that ? strings are always
> dropped on the floor.
+1 .. please go ahead and fix it!
Sanjiva.
[Axis2] dispatch of path?query valies
Posted by Steve Loughran <st...@apache.org>.
Steve Loughran wrote:
>
> 2. Addresses with ?name=value parts are not handled properly in the POST
> header or dispatch.
> (a) the ?name=value bit of the URL is duplicated in the POST.
this is fixed, but dispatch is still broken. Look. If the service URL
has a / in it, then ? string stripping engages.
But if it doesn't, then the ? string is retained in the pattern that is
then used for searching:
parseRequestURLForServiceAndOperation()
public static String[] parseRequestURLForServiceAndOperation(
String filePart) {
String[] values = new String[2];
int index = filePart.lastIndexOf(Constants.REQUEST_URL_PREFIX);
String serviceStr = null;
if (-1 != index) {
serviceStr =
filePart.substring(
index +
Constants.REQUEST_URL_PREFIX.length() + 1);
if ((index = serviceStr.indexOf('/')) > 0) {
values[0] = serviceStr.substring(0, index);
int lastIndex = serviceStr.indexOf('?');
if (lastIndex >= 0) {
values[1] = serviceStr.substring(index + 1, lastIndex);
} else {
values[1] = serviceStr.substring(index + 1);
}
} else {
values[0] = serviceStr;
}
}
return values;
}
Now, what part of RFC2616 is Axis2's URL handling exempt from? Unless I
hear a good reason wny ? params should be intermittently used for
dispatching, I am going to tweak dispatch so that ? strings are always
dropped on the floor.