supporting multiple Providers

[Brian Moseley <bc...@osafoundation.org>]

my server exposes several different types of resources, and i've found
it convenient to write a separate provider for each resource type.
however, AbstractRequestHandler and ProviderManager don't have any
extension points or other ability to make choices about which Provider
instance to use to handle a particular request.

i'm imagining a provider manager that chooses a provider instance
based on matching a URI pattern or a target's class. this would
require ProviderManager.getProvider having access to the request
context. does this seem reasonable?

for now i've taken the cheesy route of using a ProxyProvider class
that delegates all methods to one of three different providers based
on the target's class. would definitely prefer to have framework
support for this.

Re: supporting multiple Providers

[James M Snell <ja...@gmail.com>]

committed!

Brian Moseley wrote:
> On 6/12/07, James M Snell <ja...@gmail.com> wrote:
>> Definitely interesting.  will take a look in greater detail this evening
>> but I think you're on the right track here.  Given that the request
>> context can be easily ignored, I do not think there would be any need
>> for the no-arg version of getProvider
> 
> here's one that gets rid of that variant:
> 
> <http://bcm.osafoundation.org/~bcm/abdera-providermanager-2.diff>
> 

Re: supporting multiple Providers

[Brian Moseley <bc...@osafoundation.org>]

On 6/12/07, James M Snell <ja...@gmail.com> wrote:
> Definitely interesting.  will take a look in greater detail this evening
> but I think you're on the right track here.  Given that the request
> context can be easily ignored, I do not think there would be any need
> for the no-arg version of getProvider

here's one that gets rid of that variant:

<http://bcm.osafoundation.org/~bcm/abdera-providermanager-2.diff>

Re: supporting multiple Providers

[James M Snell <ja...@gmail.com>]

Definitely interesting.  will take a look in greater detail this evening
but I think you're on the right track here.  Given that the request
context can be easily ignored, I do not think there would be any need
for the no-arg version of getProvider

- James

Brian Moseley wrote:
> On 6/12/07, Brian Moseley <bc...@osafoundation.org> wrote:
>> my server exposes several different types of resources, and i've found
>> it convenient to write a separate provider for each resource type.
>> however, AbstractRequestHandler and ProviderManager don't have any
>> extension points or other ability to make choices about which Provider
>> instance to use to handle a particular request.
>>
>> i'm imagining a provider manager that chooses a provider instance
>> based on matching a URI pattern or a target's class. this would
>> require ProviderManager.getProvider having access to the request
>> context. does this seem reasonable?
> 
> here's a first pass at a patch:
> <http://bcm.osafoundation.org/~bcm/abdera-providermanager.diff>
> 
> i didn't remove ProviderManager.getProvider() because it's not clear
> to me if anybody needs the no-parameter variant or not. i can update
> the patch if folks agree that the original variant is not necessary.
> 

Re: supporting multiple Providers

[Brian Moseley <bc...@osafoundation.org>]

On 6/12/07, Brian Moseley <bc...@osafoundation.org> wrote:
> my server exposes several different types of resources, and i've found
> it convenient to write a separate provider for each resource type.
> however, AbstractRequestHandler and ProviderManager don't have any
> extension points or other ability to make choices about which Provider
> instance to use to handle a particular request.
>
> i'm imagining a provider manager that chooses a provider instance
> based on matching a URI pattern or a target's class. this would
> require ProviderManager.getProvider having access to the request
> context. does this seem reasonable?

here's a first pass at a patch:
<http://bcm.osafoundation.org/~bcm/abdera-providermanager.diff>

i didn't remove ProviderManager.getProvider() because it's not clear
to me if anybody needs the no-parameter variant or not. i can update
the patch if folks agree that the original variant is not necessary.

Re: supporting multiple Providers

[Brian Moseley <bc...@osafoundation.org>]

On 6/13/07, James M Snell <ja...@gmail.com> wrote:

> Hmm... not sure how I feel about this.  Then again, I'm not sure how I
> feel about the current Provider interface in general.

i feel pretty good about it. i like the pattern i've developed of one
provider class per resource type, with the provider chosen based on
the target class.

i did notice that some of my providers leave several methods
unimplemented. i wonder if, instead of using an interface for
providers, we could just use pojos, and somehow indicate to the
request handler which pojo methods are meant to be used for which http
method+target type combinations - maybe with annotations?

dunno that it really matters. i'm pretty satisfied with what we've got now.

> Hmmm.. could be interesting.  I was never able to find a great way of
> handling the last-modified and etag stuff outside the provider.

i'll kick down a patch in the next day or two for you to poke holes in.

Re: supporting multiple Providers

[James M Snell <ja...@gmail.com>]

Brian Moseley wrote:
> [snip]
> btw, StandardRequestHandler implements a couple other things that i
> think would be useful in the framework:
> 
> * PUT to a collection to update its state ... not specified by APP,
> but perhaps useful enough to at least have an extension point that
> doesn't require subclassing
> 

Hmm... not sure how I feel about this.  Then again, I'm not sure how I
feel about the current Provider interface in general.

> * conditional method handling ... the key is the AuditableTarget
> interface with getEntityTag and getLastModified methods

Hmmm.. could be interesting.  I was never able to find a great way of
handling the last-modified and etag stuff outside the provider.

- James

Re: supporting multiple Providers

[Brian Moseley <bc...@osafoundation.org>]

On 6/12/07, James M Snell <ja...@gmail.com> wrote:
> FWIW, It is possible to implement your own RequestHandler and
> ProviderManager implementations and use those instead.

have done ;)

<http://viewcvs.osafoundation.org/server/cosmo/trunk/cosmo/src/main/java/org/osaf/cosmo/atom/servlet/StandardRequestHandler.java?rev=4676&view=markup>
<http://viewcvs.osafoundation.org/server/cosmo/trunk/cosmo/src/main/java/org/osaf/cosmo/atom/provider/StandardProviderManager.java?rev=4665&view=markup>

btw, StandardRequestHandler implements a couple other things that i
think would be useful in the framework:

* PUT to a collection to update its state ... not specified by APP,
but perhaps useful enough to at least have an extension point that
doesn't require subclassing

* conditional method handling ... the key is the AuditableTarget
interface with getEntityTag and getLastModified methods

if either of these are interesting, let's start new threads to discuss.

Re: supporting multiple Providers

[James M Snell <ja...@gmail.com>]

FWIW, It is possible to implement your own RequestHandler and
ProviderManager implementations and use those instead.

- James

Brian Moseley wrote:
> my server exposes several different types of resources, and i've found
> it convenient to write a separate provider for each resource type.
> however, AbstractRequestHandler and ProviderManager don't have any
> extension points or other ability to make choices about which Provider
> instance to use to handle a particular request.
> 
> i'm imagining a provider manager that chooses a provider instance
> based on matching a URI pattern or a target's class. this would
> require ProviderManager.getProvider having access to the request
> context. does this seem reasonable?
> 
> for now i've taken the cheesy route of using a ProxyProvider class
> that delegates all methods to one of three different providers based
> on the target's class. would definitely prefer to have framework
> support for this.
>