Guys, I hope to cut an ALPHA2 of JBC 2.0.0 soon. After this, I want to freeze the API so there are no more changes to it during beta/cr releases, so let's get this right. The original API I proposed is on this wiki page. Since then, due to lessons learned implementing the interfaces plus a lot of feedback from the community (esp. genman) the interfaces shipped with 2.0.0.ALPHA1 was sufficiently different. And now, even more so since shipping ALPHA1. Most of the public API interfaces (CacheLoaders, CacheListeners, Regions) are ok, but some (Cache/CacheSPI/Node/NodeSPI) still needs work. Currently, these contain some changes from genman, but still pretty incomplete IMO. Here is what the Cache and Node interfaces and their implementations looks like now: Some notes: Node and Cache These are public API which will be used directly by client code (including HTTP session repl code) NodeSPI and CacheSPI These are plugin developers APIs, and are injected into CacheLoader and CacheListener implementations. They provide access to a richer set of functionailty, including access to RpcManagers, TransactionManagers, etc. Now here are the bits I have gripes with. TreeCacheProxyImpl Originally created as a delegate to link the new interfaces with TreeCache. I agree with earlier comments about this being unnecessary and TreeCache should just directly implement the new interfaces. DataNode/TreeNode/AbstractNode/WorkspaceNode malarky This lot needs revisiting, a lot of it is legacy that has been retrofitted into the new interface structure. As such, here is what I propose we do with the new structure, a great simplification: Node and Cache, and their SPIs These interfaces remain the same, offering the same functionality and public API. Cache no longer extends Node, purely for the sake of readability and reducing confusion. Cache will contain helper methods such as put(Fqn, Key, Value) but this will delegate to the root node. TreeCacheProxyImpl Is dropped, TreeCache directly implements CacheSPI DataNode and TreeNode are dropped, and AbstractNode directly implements Node. Basic functionality is implemented in this abstract class. NodeSPI and WorkspaceNode Since these offer different degrees of specialisation based on whether a node resides in a transaction workspace or not, there are 2 separate interfaces. Crucially, NodeSPI offers both versioning and locking information. UnversionedNode This is simply what used to be called NodeImpl, renamed to be a little more descriptive. Fulfils the contract of NodeSPI and is the object that is stored in memory when using pessimistic locking. Would throw UnsupportedOperationExceptions when versioning methods are invoked. Extends AbstractNode for base functionality. VersionedNode This is simply what used to be called OptimisticTreeNode, again renamed to be a little more descriptive and to break the implied fact that it is only used by optimistic locking. (At the moment this is the case but the only thing that differentiates it from other nodes is that it is versioned). Extends AbstractNode and UnversionedNode. Please let me know what you think, this should result in a much more maintainable and readable structure. Oh, and sorry about the long post! :-) Cheers, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994225#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...