Hi Azeez, On Fri, Aug 28, 2009 at 10:18 PM, Afkham Azeez <afk...@gmail.com> wrote:
> Isuru,I think that the age-old "I tested this on my machine thoroughly" > cannot be sold any longer. Like Dim's mentioned, you need to add unit tests > that demonstrates that. You also need to add unit tests to ensure that > nobody breaks the new functionality that you are trying to introduce, in the > future. > Completely agreed. I'm not telling that I covered everything. +1 for writing unit tests. Will do it definitely if we are going to put this feature in. :) Thanks, ~Isuru > > Perhaps, other people who make such changes or introduce such feature > enhancements should also do this. > > Azeez > > > On Fri, Aug 28, 2009 at 4:42 PM, Isuru Suriarachchi <isur...@gmail.com>wrote: > >> Hi Andreas, >> >> On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen < >> andreas.veit...@gmail.com> wrote: >> >>> Guys, >>> >>> Are we actually discussing the right question? Looking at the patch >>> proposed by Isuru, I have the impression that versioning is merely one >>> use case, but that (in contrast to modules) the code doesn't make any >>> assumption about the meaning of the hierarchy in the repository (it >>> could be version number, but it could also something completely >>> different). Fundamentally the change is not about versioning, but >>> about giving the user the possibility to define the structure of the >>> endpoint URL. >> >> >> Yes you are correct. >> >> >>> >>> >>> I share Deepal's concern about the possible impact of this change. He >>> mentioned the WS-Addressing case, but I believe that this change will >>> also break autogeneration of WSDLs: probably the endpoint URLs in the >>> WSDLs will be wrong. >> >> >> No. I tested WSDL auto generation and invoked few sample service of >> different types using generated WSDLs. All are working fine with correct >> EPRs. >> >> Thanks, >> ~Isuru >> >> >>> >>> >>> Andreas >>> >>> On Fri, Aug 28, 2009 at 16:45, Deepal jayasinghe<deep...@gmail.com> >>> wrote: >>> > >>> >> IMHO, service versioning & module versioning are two different things. >>> >> Module versioning is purely a deployment time concept, >>> > of course not, we can have two different version of the same module and >>> > engage the one we want based on our requirement, it is not deployment >>> > concept, it is also there in run time too. >>> >> while service versioning is both a deployment & dispatch time concept. >>> >> So there is no need to follow the same way of implementing it. I also >>> >> think that deriving the module version from the MAR name is messy, and >>> >> is not necessarily the best or better way of implementing it. >>> > There is a way that you can specify the name in the module.xml. >>> > It may be messy, but we discussed in the mailing list and implement >>> that >>> > way. >>> >> It should come from the module descriptor; module.xml. Java archives >>> >> do not have a standard way of having the version name in the artifact. >>> >> That is why OSGi introduced the bundle version in the manifest file. >>> >> So, IMO, trying to derive the name from a service, module or any other >>> >> artifact is a bad practice. >>> > I do not mind having version number in the services.xml, but I do not >>> > agree the way Isuru has implemented the version support. >>> > >>> > File name has to be unique right? I mean just because OSGi handle the >>> > version number using manifest file file name has to have the version >>> > number of some sort of unique suffix right? >>> >> >>> >> Unfortunately, there is no standard for Web service versioning, and >>> >> there are different ways of implementing it. A popular way is to make >>> >> the WSDL targetNamespace and/or the types namespace to contain the >>> >> version. >>> > I agree, sometime you need to reflect the version form tns and URL. >>> >> >>> >> Azeez >>> >> >>> >> On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe <deep...@gmail.com >>> >> <mailto: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). >>> >> >>> >> > 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) >>> >> > >>> >> > 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" ?. 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 ? >>> >> 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? how do you make sure when you change the >>> dispatcher >>> >> it does not break any of the existing features ? (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? >>> >> > 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. >>> >> >>> >> 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 >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Thanks >>> >> Afkham Azeez >>> >> >>> >> Blog: http://afkham.org >>> >> Developer Portal: http://www.wso2.org >>> >> WSAS Blog: http://wso2wsas.blogspot.com >>> >> Company: http://wso2.com >>> >> GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 >>> > >>> > >>> > -- >>> > Thank you! >>> > >>> > >>> > http://blogs.deepal.org >>> > http://deepal.org >>> > >>> > >>> >> >> >> >> -- >> Senior Software Engineer, >> WSO2 Inc. http://wso2.org/ >> Blog : http://isurues.wordpress.com/ >> > > > > -- > Thanks > Afkham Azeez > > Blog: http://afkham.org > Developer Portal: http://www.wso2.org > WSAS Blog: http://wso2wsas.blogspot.com > Company: http://wso2.com > GPG Fingerprint: 643F C2AF EB78 F886 40C9 B2A2 4AE2 C887 665E 0760 > -- Senior Software Engineer, WSO2 Inc. http://wso2.org/ Blog : http://isurues.wordpress.com/
