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<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/
