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
