"manik.surtani(a)jboss.com" wrote : anonymous wrote : | | Also, I'd like to hear some feedback on this issue: http://jira.jboss.com/jira/browse/JBCACHE-890 . I think we may want to add a couple of flags (three already come to mind.) Multiple booleans might be sufficient for the moment. Still, having a way to extend things cleanly might be nice in 2.0. | | | | Start a separate thread on this. I think that having such dynamically set series of flags on a node is a bit weird, wonder if we're better off with a limited set of getters/setters. I think a get/set(boolean) for the NodeSPI is fine. I'm more concerned about the underlying implementation: It's just likely that the set of properties of a node will expand over time. What will inevitably happen is you'll want to add more methods to NodeSPI. The idea is to add some potential for future expansion. If you think of the Tree as somewhat modeled off of a file system, the need for meta-data comes up time and time again. Maybe Java annotations can serve this role? But really you need something more dynamic. anonymous wrote : | Finally, from this hierarchy, I still don't see a clean way to access CacheSPI (or NodeSPI), except to do: | | CacheSPI spi = (CacheSPI)cache; | I "proposed" the API to access the node SPI should be Node.getNodeSPI(). This was cleaner rather than having to make an iffy cast all the time. I believe that a Cache.getCacheSPI() would be for the best. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994779#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...