Azeez,

Absolutely +1 to "people who make such changes or introduce such feature enhancements should also do this."

-- dims

On 08/28/2009 12:48 PM, Afkham Azeez 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.
>
> 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<isurues@gmai...>wrote:
>
>> Hi Andreas,
>>
>> On Fri, Aug 28, 2009 at 8:30 PM, Andreas Veithen<
>> andreas.veithen@gmai...>  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<deepalk@gmai...>
>>> 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<deepalk@gmai...
>>>>> <mailto: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
>>>>>      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/
>>
>
>
>