Hi Azeez,

On Fri, Aug 28, 2009 at 10:18 PM, Afkham Azeez <afkham@gmai...> 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 <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/
>>
>
>
>
> --
> 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/