Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of deepalk@gmail.com designates
 209.85.217.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=kPv0rCvMnCcVgMGgQVVX8cELSqMiByM2bTSof2fzT5qenfiYSGAgcfS1Wfiv9Tg4Qu
         liOmO4Pb794OyrGX4xOeKN65rDXAZ4rrtpaGkE9/6APB6B4+A/6gB72tQGjlFoXvbBDx
         gyQDNIXoeGCwA7088/SMHiQOL9qZUxnsZx2xg=
Message-ID: <4A98115E.7030901@gmail.com>
Date: Fri, 28 Aug 2009 13:18:22 -0400
From: Deepal jayasinghe <deepalk@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: Supporting hierarchical service deployment
References: <b729442d0908280205m315141b7u74e092dda7b47b4c@mail.gmail.com>
	 <4A97DCFC.4030708@gmail.com>
 <b729442d0908280938h7dfe8b85q7a6dc4756b1f86a5@mail.gmail.com>
In-Reply-To: <b729442d0908280938h7dfe8b85q7a6dc4756b1f86a5@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


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