Andreas, you are right. It is not only about the version number. The hierarchy may semantically reflect the version number. It could be used for many things. e.g. in a multi-user/multi-tenant deployment, all services of a particular user/tenant can be stored under a certain directory. This structure is also reflected in the endpoint addresses. Azeez
On Fri, Aug 28, 2009 at 3:00 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. > > 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. > > 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 > > > > > -- 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
