On Fri, Nov 20, 2009 at 3:36 AM, Supun Kamburugamuwa <[email protected]> wrote:

> At the moment there is no way of getting the request parameters as message
> context properties. So do you think introducing a XPath variable context is
> the right solution?
>

I've done this and it works. But want to get your ideas weather this is the
correct solution.

Supun..


>
> This brings me to another question. How about improving the XPath support
> of Synapse to be an extension point of Synapse?
>
> Thanks,
> Supun..
>
>
> On Thu, Nov 19, 2009 at 9:21 AM, Ruwan Linton <[email protected]> wrote:
>
>> Supun Kamburugamuwa wrote:
>> > Sorry they can be GET or POST
>> In that case it is a valid scenario, for GET requests all your
>> requirements can be achieved even now. For POST requests with URL
>> parameters in the request URL, URL re-write will be important.
>>
>> Thanks,
>> Ruwan
>> >
>> > Thanks,
>> > Supun..
>> >
>> > On Wed, Nov 18, 2009 at 7:46 PM, Supun Kamburugamuwa <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> >     Yes, they are GET requests.
>> >
>> >     Thanks,
>> >     Supun..
>> >
>> >
>> >     On Wed, Nov 18, 2009 at 5:46 PM, Ruwan Linton <[email protected]
>> >     <mailto:[email protected]>> wrote:
>> >
>> >         Supun, is this a HTTP GET request??
>> >
>> >         Thanks,
>> >         Ruwan
>> >
>> >         Supun Kamburugamuwa wrote:
>> >         > Hi,
>> >         >
>> >         > I'll first explain the requirements.
>> >         >
>> >         > Lets say ESB get a URL like this.
>> >         >
>> >         >
>> >         http://localhost:8280/services/Myproxy/mytest?test1=1&test2=2
>> >         <http://localhost:8280/services/Myproxy/mytest?test1=1&test2=2>
>> >         >
>> >         <http://localhost:8280/services/Myproxy/mytest?test1=1&test2=2
>> >         <http://localhost:8280/services/Myproxy/mytest?test1=1&test2=2
>> >>
>> >         >
>> >         > You can see above request is coming in to the proxy named
>> >         Myproxy.
>> >         > There are two requirements.
>> >         >
>> >         > First requirement is URL re-writing and second one is to
>> extract
>> >         > parameters from the URL.
>> >         >
>> >         > *URL-rewriting*:
>> >         >
>> >         > For example the second URL will be something like
>> >         >
>> >         >
>> >
>> http://myservice:9000/services/mySecondService/mytest?test1=1&test2=2
>> >         <
>> http://myservice:9000/services/mySecondService/mytest?test1=1&test2=2>
>> >         >
>> >         <
>> http://myservice:9000/services/mySecondService/mytest?test1=1&test2=2
>> >         <
>> http://myservice:9000/services/mySecondService/mytest?test1=1&test2=2>>.
>> >         > You can see that this is URL rewriting. We are getting a URL
>> >         to one of
>> >         > resources inside ESB and ESB send it to another service. The
>> >         second
>> >         > URL is constructed by appending the things that doesn't
>> >         belong to the
>> >         > Myproxy resource URL to the second resource. Ideal user
>> >         expectation
>> >         > is, there is a configuration in the Endpoint saying
>> >         something like
>> >         > url-rewrite=true. Then this will automatically happen or
>> >         there is a
>> >         > property.
>> >         >
>> >         > Do you think this is a genuine requirement in case of ESB?
>> >         Note this
>> >         > is specific to HTTP transport.
>> >         >
>> >         > *Parameter extraction:*
>> >         >
>> >         > The next requirement is to extract the parameters from the
>> >         URL. I have
>> >         > started to do this by introducing a new XPath variable
>> >         context. For
>> >         > example you can get the parameter named test1 by a XPath
>> >         expression
>> >         > like $url:test1. But it seems there is no way to get  the
>> >         parameters
>> >         > directly from Axis2. Instead we only have access to the full
>> >         URL. In
>> >         > that case we need to break it down manually. Do you think
>> >         this is the
>> >         > correct approach or is there a way to get the parameters
>> >         directly from
>> >         > a hash map?
>> >         >
>> >         > Thanks,
>> >         > Supun..
>> >         >
>> >
>> ------------------------------------------------------------------------
>> >         >
>> >         > _______________________________________________
>> >         > Carbon-dev mailing list
>> >         > [email protected] <mailto:[email protected]>
>> >         > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>> >         >
>> >
>> >
>> >         --
>> >         Ruwan Linton
>> >         Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> >         WSO2 <http://wso2.org/esbWSO2> Inc.; http://wso2.org
>> >         email: [email protected] <mailto:[email protected]>; cell: +94 77
>> >         341 3097
>> >         blog: http://blog.ruwan.org
>> >
>> >
>> >
>> >         _______________________________________________
>> >         Carbon-dev mailing list
>> >         [email protected] <mailto:[email protected]>
>> >         https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Carbon-dev mailing list
>> > [email protected]
>> > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>> >
>>
>>
>> --
>> Ruwan Linton
>> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
>> WSO2 <http://wso2.org/esb%0AWSO2> Inc.; http://wso2.org
>> email: [email protected]; cell: +94 77 341 3097
>> blog: http://blog.ruwan.org
>>
>>
>>
>> _______________________________________________
>> Carbon-dev mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>
>
_______________________________________________
Carbon-dev mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to