More flexible servicesPath for ServiceProvider

[Jim Ancona <ji...@anconafamily.com>]

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.

Jim

Re: More flexible servicesPath for ServiceProvider

[Jim Ancona <ji...@anconafamily.com>]

Dan Diephouse wrote:
> #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.

I will be submitting a patch to do #2 (make the default implementation 
use a regex rather than a simple string match) today. Refactoring to 
make the match method replaceable looked like more than I had time to 
take on at the moment.

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

I wasn't aware of CollectionProvider/ServiceProvider before your email 
about the changes you made last month. I had already done some work 
using ServiceProvider and had written my own MultiProviderServiceContext 
to do something similar, but I have junked that because the 
ServiceProvider solution is much cleaner than mine was. The only things 
I've seen missing is the support for parameterized URIs that my patches 
address.

Thanks!

Jim

Re: More flexible servicesPath for ServiceProvider

[Dan Diephouse <da...@mulesource.com>]

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