synapse-devs, Extending this discussion, we need to figure out the position to place the configuration point in order to configure the behavior of the GET request over the service path.
I prefer the nhttp.properties file since this is completely on the (http) transport level and an entry named "get_on_service" having values "wsdl", "info" ... etc. (we can add more to this once there are more filters like what Chinthaka suggested, but I don't think displaying policy and schema is useful even though we can have them too) Thoughts? Thanks, Ruwan On Dec 15, 2007 8:51 PM, <[EMAIL PROTECTED]> wrote: > Sorry a minor correction to the earlier mail > > On 12/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi Chinthaka, > > > > If you look at my proposal carefully there I have stated about a > > configuration point on which the behavior of the GET request over the > > service path will be determined from one of the wsdl or service path. > > ^^^^^^^^ ^^^^^ > (here the service path should be changed to service information :() > > May be we can add this (the feature you described which is already > > supported by XFire) also as an option to that configuration so that we > > can support that. > > > > In effect that configuration specify the behavior of the service path > either > > as > > * the service wsdl > > * the service information > > * or the operation which is exposed at the service path (obviously > > this operation should not expect any parameters) > > > > I also think this is a good feature to implement. > > > > Thanks, > > Ruwan > > > > On 12/14/07, Eran Chinthaka <[EMAIL PROTECTED]> wrote: > > > Hi Ruwan, > > > > > > This is certainly a good feature if you can add. But I can remember > > > XFire was doing something similar to this. This is how it worked, > IIRC. > > > > > > If you have a service (say Foo) with only one operation (bar) , then > > > when you invoke the service (without the operation name), then that > > > request goes to the only operation. Meaning both > > > http://<host>:<port>/axis2/services/Foo and > > > http://<host>:<port>/axis2/services/Foo/bar are the same. > > > > > > If this bar operation adheres to IRI style (please check IRI style in > > > WSDL 2.0 spec), then doing a GET operation on this service should > invoke > > > bar operation in a RESTful manner (oops, POX over HTTP). > > > > > > So if you implement GET request to return the service description, > then > > > there might be conflict. If you just invoke the operation with > > > http://<host>:<port>/axis2/services/Foo, then axis2 will send the > famous > > > operation not found error. I know the above feature is not > implemented. > > > , but that is something cool I saw in XFire. > > > > > > This is just a suggestion and noway this should be considered as an > > > objection to your initial proposal. A small disclaimer ;) > > > > > > Thanks, > > > Chinthaka > > > > > > Ruwan Linton wrote: > > > > Hi axis2 folks, > > > > > > > > We (synapse-dev) is in the process of doing some refactoring on the > GET > > > > request processors. For the moment we do provide a service > information > > > > html page on doing a GET request on the service path and discussing > to > > > > add a ?info filter for that and keep the original service path for > any > > > > other thing (may be we can provide a configuration point so that > user > > > > can configure that path to provide the wsdl of the service instead) > > > > > > > > What is the behavior of the axis2 in this service path navigation > > > > through a browser (or else doing a GET request over the service > path) > > > > and what do you guys think about this improvement? > > > > > > > > Thanks, > > > > Ruwan > > > > > > > > On Dec 10, 2007 11:52 PM, Asankha C. Perera <[EMAIL PROTECTED] > > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > Ruwan > > > > > > > > I think what we do right now is the same that a vanilla Axis2 > would > > > do.. > > > > I am not sure if axis2 supports a ?info though, can we check on > > > > axis2-dev/user too? > > > > > > > > thanks > > > > asankha > > > > > > > > Ruwan Linton wrote: > > > > > Hi all, > > > > > > > > > > For the moment if we browse to the service path (for example > if > > we > > > > > have a proxy service named xxx, then this path is > > > > > http://{host}:{port}/soap/xxx), in other words if we do a GET > > > > request > > > > > on the service path synapse displays the service information > as > > > pure > > > > > HTML content. > > > > > > > > > > Rather than directly displaying these service information on > the > > > > > service path what if we keep that path separate and use ?info > > > filter > > > > > to retrieve the service information (i.e. > > > > > http://{host}:{port}/soap/xxx?info will display the service > > > > information) > > > > > > > > > > May be we can define a configuration point on which we can > define > > > > what > > > > > will be available under the service path (it can be the > service > > > WSDL > > > > > or the service info or else any other thing, if you define a > > > filter). > > > > > At the same time we can keep the ?wsdl, ?policy and the ?xsd > like > > > > > filters also configurable so that one can define what each of > > these > > > > > would do. I think this adds better flexibility and control > over > > the > > > > > GET request processing. > > > > > > > > > > WDYT? > > > > > > > > > > Thanks, > > > > > Ruwan > > > > > > > > > > -- > > > > > Ruwan Linton > > > > > http://www.wso2.org - "Oxygenating the Web Services Platform" > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > -- > > > > Ruwan Linton > > > > http://www.wso2.org - "Oxygenating the Web Services Platform" > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Ruwan Linton > > http://www.wso2.org - "Oxygenating the Web Services Platform" > > > > > -- > Ruwan Linton > http://www.wso2.org - "Oxygenating the Web Services Platform" > -- Ruwan Linton http://www.wso2.org - "Oxygenating the Web Services Platform"
