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"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
