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
