>
> Yes this introduces new URL patterns. To be exact, the URI based
> dispatcher treats the '/' character to separate service name and
> operation name (if any). But in this new case, service name can have
> '/' character.
Dont you think that is confusing ? how do you know whether it is service
version or the operation ?
> If look at my patch carefully, I have handled this without affecting
> the existing behaviour. It first tries to find the service in the
> normal manner. If not found, checks whether this is a hierarchical
> service.
I already commented on this by looking at the patch. The way you have
handle is not correct.
>
>
>
>
> > 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)
>
>
> Yes you can do that. But when you implement that, it introduces '.'
> characters into the service name. That clashes with the logic to
> identify the endpoint.
Yes this endpoint concept is something we introduce in wrong way, which
broke some of the useful scenarios.
> Therefore even if you do it that way, most of my fixes are needed.
If the "." is taken we can take something else like "-", which would
nice and easy than having "/"
>
>
> Can you please explain some real scenarios in which this breaks the
> existing functionality?
When you add "if-else" statement into your code, which add two control
paths, so we need to test all of them. Second when you do some code
changes on critical path how do you make sure that you do not break
anything. If you want any proof just go and look axis mail archives,
some times people do very small modification and it took a long time to
identify and fix them.
