I've commented on a couple things which I have other thoughts on, but
overall it looks good.
James M Snell wrote:
The default provider implementation will extend
AbstractWorkspaceManagerProvider.java. This class implements boththe
Provider and WorkspaceManager interfaces.
I would also like to float the idea that the Provider should take a
WorkspaceManager as a property/constructor. This way I as a user just
implement WorkspaceManager which can look up collections from my
database and pass it in as an argument to some stock Provider.
The WorkspaceManager is equivalent to the current WorkspaceInfo
interface. It's primary function is to lookup the appropriate
CollectionAdapter instance.
We still need a way to describe the workspaces though. A la
WorkspaceInfo.getName/getCollectionProviders. Are you sure we don't need
WorkspaceInfo still?
A CollectionAdapter instance can choose to implement the Provider
interface in order to support extension methods.
I'm not sure that provider is the right interface to do this as it mixes
semantics a little bit. My alternative proposals would be to either:
1. have a fallback method built into CA like doOther(RequestContext) or
something like that.
2. Make the Provider responsible for choosing a method via some sort of
extensible dispatching mechanism
A CollectionAdapter instance can choose to implement the Transactional
interface if it wishes to support begin/end/compensate semantics.
I think this might be going a little bit overboard here in terms of
interfaces. I would rather lean toward building this into the
AbstractCollectionAdapter itself. A la the code snippet I published
earlier which called begin/end inside.
BTW, I also think we'll need to have begin/end points which we can
intercept in the actual Provider implementation itself.
Overall, I like the simplified flow and increased coherency!
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
