Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4783F344.4040404@mulesource.com>
Date: Tue, 08 Jan 2008 17:03:48 -0500
From: Dan Diephouse <dan.diephouse@mulesource.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: More flexible servicesPath for ServiceProvider
References: <47839BBB.4010806@anconafamily.com>
In-Reply-To: <47839BBB.4010806@anconafamily.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jim Ancona wrote:
> As I mentioned in the issue I just created 
> (https://issues.apache.org/jira/browse/ABDERA-85), I have a use case 
> where the base URI of my service is parameterized (e.g. 
> http://example.com/users/{userId}/service/). I want to use a 
> ServiceProvider at the user level, i.e. I would like the servicesPath 
> to match http://example.com/users/{userId}/. The current 
> implementation in AbstractServiceProvider uses a plain string match, 
> so there's no way to parameterize it.
>
> I have created a class extending AbstractServiceProvider which matches 
> using a regex. It also stores the match value(s) as request 
> parameter(s), making them easily accessible to my CollectionProvider. 
> While my class meets my needs, I think the use case is common enough 
> that you might want to incorporate something similar into Abdera. I 
> had to override AbstractServiceProvider.resolve() in my class, which 
> lead to quite a bit of duplicated code. It might be better to:
>
> 1. Refactor AbstractServiceProvider to abstract the string matching 
> into separate methods, so that classes that want to use a different 
> matching method can easily do so.
>
> 2. Make the default implementation use a regex rather than a simple 
> string match.
>
> You could do either of those, or both (or neither :-)). I'm willing to 
> provide a patch for whichever option(s) are preferred.
>
> Thanks for considering this.
>
Great idea. I too have had to extend ServiceProvider this week and found 
it highly annoying. But I haven't had a chance to look at how to improve 
it.

#2 sounds interesting as it would not require any code. A patch would be 
most welcome.  I suppose it could even be combined with #1 while we're 
at it in case people want to override the regex.

Other than that - is the service provider code working for you OK? Did 
it make sense pretty easily?

- Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog