On Fri, Aug 28, 2009 at 10:08 PM, Isuru Suriarachchi <isur...@gmail.com>wrote:
> Hi Deepal, > > Please see my comments inline. > > On Fri, Aug 28, 2009 at 7:04 PM, Deepal jayasinghe <deep...@gmail.com>wrote: > >> Hi Isuru, >> >> Thank you for taking your time and looking to this issues, but I do not >> agree the way you have address it, please see my comments below. The >> reason I am telling this is, as I can see this has so many issues, and >> you have made it complicated too :) . I believe you might know that we >> have version support for modules and we do not handle that like this. So >> this simply break the consistency, and this introduce new URL patterns , >> though you have not encounter now, I am sure you are going to face a >> number of issues (when it come to dispatching). > > > Yes this introduces new URL patterns. To be exact, the URI based dispatcher > treats the '/' character to separate service name and operation name (if > any). But in this new case, service name can have '/' character. If look at > my patch carefully, I have handled this without affecting the existing > behaviour. It first tries to find the service in the normal manner. If not > found, checks whether this is a hierarchical service. > > >> >> >> > Currently Axis2 can only deploy services at the repository/services >> > level. This makes it impossible to deploy several versions of the same >> > service. >> I do not agree, you can have the version name in the aar file, for >> example foo-1.0.aar and foo-1.1.aar. Then at the deployment time just >> append the version number to the service name (to make the service name >> unique) > > > Yes you can do that. But when you implement that, it introduces '.' > characters into the service name. That clashes with the logic to identify > the endpoint. Therefore even if you do it that way, most of my fixes are > needed. And also this hierarchical service deployment is not only about > having different versions. It allow you to have your own structure in the > service URL. > > >> >> > >> > Therefore, I've improved our deployment engine to deploy services by >> > looking at the hierarchical path of the service. For example this >> > allows us to deploy a service repository/services/foo/bar/version.aar. >> > And also this allows us to deploy any number of services as follows. >> > repository/services/versionService/1.0.0/version.aar >> > repository/services/versionService/1.0.1/version.aar >> Don't you think this is complex ? what is different between >> "services/versionService/1.0.1/version.aar" and >> "services/version-1.0.1.aar" ?. > > > Again the same answer. This is not only about versioning. It give you the > ability to define the structure of your service URL. > > >> As far as I know second one is better >> than the first one (and you do not need much modification to handle >> that). Which is the commonly used approach for all sort of version >> management. (am I missing something?) >> > >> > In the implementation, I've attached the hierarchical part of the >> > service (versionService/1.0.1/) in front of the service name which is >> > read from the services.xml. And also I've fixed the URI based >> > dispatching logics to dispatch the services correctly. >> Then how about addressing based dispatching ? > > > Even in addressing scenario, existing service (in repository/services > folder) dispatching is not affected at all. I didn't test it for > hierarchical services yet and ill update the thread after having a look at > that. > I tested a hierarchical service and a normal service with addressing as well. Both cases work without any trouble. When both RequestURIBasedDispatcher and SOAPActionBasedDispatcher are set in Transport phase, AxisService if found in the RequestURIBasedDispatcher and the AxisOperation is found in the SOAPActionBasedDispatcher by looking at the SOAP action. Addressing dispatcher just verifies the stuff. In order to make sure Addressing based operation dispatching works, I just removed SOAPActionBasedDispatcher from the Transport phase. In this case, AxisOperation is found in the Addressing based dispatcher without any trouble. All these scenarios are working with hierarchical services. Here is the SOAP request with the addressing header which was sent in my sample. ======================================= POST /axis2/services/bar/1.0.1/Version.VersionHttpSoap12Endpoint/ HTTP/1.1 Content-Type: application/soap+xml; charset=UTF-8; action="urn:getVersion" User-Agent: Axis2 Host: 127.0.0.1 Transfer-Encoding: chunked 1b5 <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope "> <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing";> <wsa:To> http://localhost:8091/axis2/services/bar/1.0.1/Version.VersionHttpSoap12Endpoint/ </wsa:To> <wsa:MessageID>urn:uuid:769BBB9C380BF51AA21251531417821</wsa:MessageID> <wsa:Action>urn:getVersion</wsa:Action> </soapenv:Header> <soapenv:Body /> </soapenv:Envelope> ============================================ Thanks, ~Isuru > > > >> >> I remember the mess we had when someone introduce portName into the URL, >> I think we still have issues with that (though no one uses the feature). >> > >> > This improvement doesn't affect any of the existing functionalities. >> Of course it does? > > > Can you please explain some real scenarios in which this breaks the > existing functionality? > > >> how do you make sure when you change the dispatcher >> it does not break any of the existing features ? > > > It's because in the code I've always given the priority to the existing > behaviour. And also I tested it for may scenarios including REST and all. > But I didn't find any issues. But Of course I could have missed something.. > :) > > >> (we do not have enough >> test cases to cover all the cases) I think I have enough experience in >> Axis2, what when someone change something hoping that does not break >> something. >> > The only limitation of this is we can't deploy a RESTful service in >> > this manner. >> This is a problem right? >> When the system move from one version to other, client will notice that >> the service does not work any more? > > > I think you have understood this in the wrong way. This feature will not > cause any problems as far as you have your RESTful service in the > repository/service folder. I tested that scenario and it works. What I > mentioned above is we can't deploy a RESTful service hierarchically. Ex: > services/foo/1.0.0/RESTservice.aar. > > >> >> > Those can only be supported at repository/service level. That is >> > because, incoming URL of a RESTful service can contain '/' separated >> > parameters to the service. >> oh boy, you are making system tooooooo, complicated. > > > Why do you think that way? If you look at my patch carefully, I've > implemented it with a minimum affect to the existing code. > > Thanks, > ~Isuru > > >> >> >> I am sorry I am -1 on this approach, we need to discuss this before we >> implement. >> In fact I remember we had some discussion on this at one of the >> apachecon, there also we did not come to a conclusion. >> >> Thanks, >> Deepal >> > > > > -- > Senior Software Engineer, > WSO2 Inc. http://wso2.org/ > Blog : http://isurues.wordpress.com/ > -- Senior Software Engineer, WSO2 Inc. http://wso2.org/ Blog : http://isurues.wordpress.com/
