CollectionProvider improvements

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

I've been working with the CollectionProvider stuff a bit more, but I've 
run into a couple limitations. I don't think they're insurmountable, but 
I wanted to hear what people though about the possible solutions.

The problems that I've run into are main along two lines:
1. A developer will need access to information which isn't explicitly 
part of the AbstractCollectionProvider methods. For instance, lets say 
someone is GETing a collection, but they've specified some open search 
query parameters. These are not passed into the 
AbstractCollectionProvider.getEntries method. Which leaves them up a creek.

2. Sessions/Transactions. I was toying with a JCR collection 
implementation. JCR requires that we start a session at the beginning of 
the request and logout of the session at the end. You also need to have 
access to the Session inside your CollectionProvider implementation.

I can think of a few possible solutions to these things, but they're all 
kind of ugly IMO.

1. Supply the RequestContext to the user via a ThreadLocal variable. Or 
in the case of #2, supply the Session via a ThreadLocal variable and 
provide hooks inside the Provider to do things at the beginning/end of 
the request. This is probably my least favorite option.

2. Change the scope of CollectionProviders from singleton to request 
scope and set properties on the CollectionProvider. In essence each 
request would do something like this

public ResponseContext getEntry(RequestContext cxt) {
CollectionProvider cp = workspace.createCollectionProvider(...);
// make the context available via CollectionProvider.getRequestContext()
cp.setRequestContext(context);

// do custom session creation logic
initializeCollectionProvider(cp);

Entry entry = ...;
Object entryObj = cp.getEntry(resourceName);
entry.setTitle(cp.getTitle(entryObj ));
entry.setAuthor(cp.getAuthor(entry));
... etc.

// do custom session logout logic
destroyCollectionProvider(cp);

Creating a new CP seems slightly annoying to me, but this seems to be 
the cleanest solution.

3. Add a RequestContext variable to most/all of the CollectionProvider 
methods:

public abstract Iterable<T> getEntries(RequestContext ctx) throws 
ResponseContextException;
public abstract <T> T getEntryFromId(String id, RequestContext ctx) 
throws ResponseContextException

For the session/tx use case, the Session can be set inside the 
RequestContext and pulled out via ctx.getAttribute().  The thing I don't 
like about this option is that it adds clutter.

-- 

I get this feeling though that I'm missing some better paradigm. Any one 
have better ideas? (or did this make any sense at all?)

- Dan

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

Re: CollectionProvider improvements

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

On 10/28/07, James M Snell <ja...@gmail.com> wrote:
> I don't have any strong opinions about this other than really wanting to
> make sure things stay fairly simple.

same.

> Dan Diephouse wrote:
> > 3. Add a RequestContext variable to most/all of the CollectionProvider
> > methods:
> >
> > public abstract Iterable<T> getEntries(RequestContext ctx) throws
> > ResponseContextException;
> > public abstract <T> T getEntryFromId(String id, RequestContext ctx)
> > throws ResponseContextException
> >
>
> +1

+1

> > For the session/tx use case, the Session can be set inside the
> > RequestContext and pulled out via ctx.getAttribute().  The thing I don't
> > like about this option is that it adds clutter.

does this call for an HttpRequestContext subtype that has a getSession
method? still kind of annoying to cast, but less clutter than using an
attribute.

Re: CollectionProvider improvements

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

I don't have any strong opinions about this other than really wanting to
make sure things stay fairly simple.  With that said, comments below.

Dan Diephouse wrote:
> [snip]
> The problems that I've run into are main along two lines:
> 1. A developer will need access to information which isn't explicitly
> part of the AbstractCollectionProvider methods. For instance, lets say
> someone is GETing a collection, but they've specified some open search
> query parameters. These are not passed into the
> AbstractCollectionProvider.getEntries method. Which leaves them up a creek.
> 

EWww.. that's bad.  This is precisely why the RequestContext object
exists.  We need to make sure the context is always available.

> [snip]
> 1. Supply the RequestContext to the user via a ThreadLocal variable. Or
> in the case of #2, supply the Session via a ThreadLocal variable and
> provide hooks inside the Provider to do things at the beginning/end of
> the request. This is probably my least favorite option.
> 

-1. Not a good option.

> 2. Change the scope of CollectionProviders from singleton to request
> scope and set properties on the CollectionProvider. In essence each
> request would do something like this
> 

This would be fine so long as we have the option of pooling the
CollectionProviders.  Instances of the provider should not maintain
request state.

> public ResponseContext getEntry(RequestContext cxt) {
> CollectionProvider cp = workspace.createCollectionProvider(...);

An ItemManager instance could be used here to enable pooling.

> // make the context available via CollectionProvider.getRequestContext()
> cp.setRequestContext(context);

-1. I'd rather see something like cp.getEntry(context)

> [snip]
> 3. Add a RequestContext variable to most/all of the CollectionProvider
> methods:
> 
> public abstract Iterable<T> getEntries(RequestContext ctx) throws
> ResponseContextException;
> public abstract <T> T getEntryFromId(String id, RequestContext ctx)
> throws ResponseContextException
> 

+1

> For the session/tx use case, the Session can be set inside the
> RequestContext and pulled out via ctx.getAttribute().  The thing I don't
> like about this option is that it adds clutter.
> 

- James