RE: [jbosscache-dev] API changes in Habanero

OK, so we are saying XXxDirect belongs in NodeSPI because they are used only for cache behavior customization? But I'd like the explict naming in this case. Previously, you always need to remember to set the option each time before the method call. Another minor issue that I find in my unit test: java.lang.UnsupportedOperationException: Cannot directly retrieve children which aren't directly under the current node. at org.jboss.cache.UnversionedNode.getChildDirect(UnversionedNode.java:424) It seems now: NodeSPI node = cache.getRoot().getChildDirect(fqn); Only support the retrieval of immediate child. So if, say, I have "/a/b/c" fqn that I want to retrieve from getRoot(), what is my option then? I'd think to iterate through the Node tree to get a child node is quite tedious and inefficient. Thanks, -Ben -----Original Message----- From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Manik Surtani Sent: Thursday, January 04, 2007 10:47 PM To: jbosscache-dev(a)lists.jboss.org Subject: [jbosscache-dev] API changes in Habanero Guys, Here are a few major refactorings I've done on HEAD (checked in already). Some of these are on the API level and do affect the way interceptors and other subsystems interact with the node structure, hence the email. * Got rid of the horrible BypassInterceptorChain malarky when interacting with nodes and you don't want calls up the interceptor chain * Used by interceptors themselves, as well as other internal subsystems including state transfer and the cache itself. * BypassInterceptorChain will still exist as an Option, as there are some valid use cases for this. * This option is now SOLELY handled by the InvocationContextInterceptor, which directs the call to the last interceptor in the chain if the option is present * Not handled internally in Node implementation methods anymore * Replaced with a bunch of XXXDirect() methods on NodeSPI for direct interaction/bypassing interceptor chains * E.g., Node.getChild(Fqn f) goes up the interceptor chain, NodeSPI.getChildDirect(Fqn f) operates directly on the node. * Benefits: much easier to read, understand and maintain, more performant. * Got rid of Node.getNodeSPI() * NodeSPI interface can now be easily obtained since all methods on NodeSPI which would otherwise return Node now return NodeSPI * Methods on Cache (such as getRoot()) which would return Node are overridden in CacheSPI to return NodeSPI. * Gives interceptors and the like access to NodeSPI without letting this interface escape to the user API. * There are still a very small handful of cases where direct casts are necessary, but this is very internalised (within UnversionedNode and WorkspaceNode, for example) and a bunch of unit tests (for closer inspection) * In general, NodeSPI is now much tighter and can only officially be obtained from another NodeSPI or a CacheSPI. * Got rid of NodeSPI.getRawData() - superfluous now that we have NodeSPI.getDataDirect() This stuff should give us a much more robust data model and user/SPI interface for the nodes and caches. Please let me know what you think or if you have any issues/further suggestions. Cheers, -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev