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
