> IMHO, service versioning & module versioning are two different things.
> Module versioning is purely a deployment time concept, 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. 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.
> 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.
> On Fri, Aug 28, 2009 at 1:34 PM, Deepal jayasinghe <deepalk@gmai...>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
>> > 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
>> > 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
>> In fact I remember we had some discussion on this at one of the
>> apachecon, there also we did not come to a conclusion.
> 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