"manik.surtani(a)jboss.com" wrote : | "genman" wrote : | | There really should be options you can set to override loading from the cache loader, or for ignoring the return values for Node.put(key, value) or Node.remove(key) . | | | Yes, but then you change the behaviour of put() and remove(), which IMO should not be controlled by an option. Perahps add a putQuietly() or removeQuietly() that have return types of void, although this clutters up the API which sucks. | The AsyncCacheLoader has an option to allow remove() and put() (single key) operations to return null instead of the old value. This allows these operations to be queued rather than making the caller wait. Anyway, I thought the point of the options was to send hints to the system, such as "Don't wait to put() if the node is already locked." I would think "I don't need to know the return value for this operation" would be a somewhat similar use case. "manik.surtani(a)jboss.com" wrote : | "genman" wrote : | | It would be nice if there was a "disable()" method on Interceptor. Interceptor.invoke() might have been public/final and delegated to a protected abstract method ... | | Well, unless disabling was conditional (i.e., disable for all get() calls) you may as well yank the interceptor out of the chain. The thing with the removal and addition of interceptors is ... the APIs are a little hokey. Working with index numbers isn't as nice as with objects. I was thinking (and it's too late to change, but ...) Interceptors themselves have a specific dependency or ordering to them. And rather than specify the ordering explicitly, the API would be add(Interceptor). You could have a remove(Interceptor) (symmetric call) as well that scans using object identity. I do agree that bypassing certain interceptors should be drive by options, not an API call. (It'd be nice if this was done in some generic way. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065262#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...