-
1. Re: JBCACHE-106 - passing in options
belaban Oct 27, 2005 12:50 PM (in response to manik)"manik.surtani@jboss.com" wrote:
http://jira.jboss.com/jira/browse/JBCACHE-106
How would we actually pass in options to put, get and remove methods?
Ugly but extensible: a method parameter of Option[] where Option is an object containing a name (String) and value (Object).
-1
Would people prefer a Map of options?
-1
Can we think of a better way to do this, perhaps an Options object that contains getters and setters for each option we'd allow? Or would this get real ugly real quick once we support every configurable option in the global cache?
+1. I think there will always be only a limited number of options we allow callers to override, so having an Options object with typed properties is good. -
2. Re: JBCACHE-106 - passing in options
jerrygauth Oct 27, 2005 1:00 PM (in response to manik)I've seen the Options object approach used successfully. It's not as dynamic as the other approaches since you'll need to modify the Options class to introduce new options. But it can ensure that all parameters are valid since you can edit the options in the Option class rather than in the put, get and remove methods.
Another possibility if you're requiring JDK5 is to use variable arguments.
Would the set of supported options be identical for all methods? If not, this might affect how you design an Options object.
My preference would be for the Options object or the Map object. -
3. Re: JBCACHE-106 - passing in options
manik Oct 27, 2005 1:12 PM (in response to manik)JDK5's variable args is the effect we're trying to achieve without binding ourselves to JDK5.
Would the set of supported options be identical for all methods? If not, this might affect how you design an Options object.
No, not all options will apply to all methods.
Bela, we could go for an Options interface, and extend this interface for each method we'd use it with, and have an Impl object for each? Or would you rather call the interface IOptions? ;) jk!
I'd stick with a single Options object used by all methods since _most_ options would apply to all methods. -
4. Re: JBCACHE-106 - passing in options
belaban Oct 27, 2005 1:12 PM (in response to manik)Variable arg lists are not an option as we need to be JDK 1.4 compatible, at least for now
-
5. Re: JBCACHE-106 - passing in options
adrian.brock Oct 27, 2005 1:29 PM (in response to manik)varargs is just syntatic suger over:
public void doSomething(Object[] parameters) -
6. Re: JBCACHE-106 - passing in options
adrian.brock Oct 27, 2005 1:40 PM (in response to manik)Why are you trying to solve problems that are already solved elsewhere?
I am continually worried that JBossCache is trying to become a platform
rather than just a "do one thing well" caching implementation.
Build a platform on top of it by all means,
but do it at a separate level of abstraction,
don't do it at the expense of the basic problem you are trying to solve!
For the record (in case you don't already know :-), I hate FAT interfaces.
http://www.google.com/search?hl=en&q=FAT+interfaces
e.g. JMX suffers from this as well with its "do everything" MBeanServer interface. -
7. Re: JBCACHE-106 - passing in options
adrian.brock Oct 27, 2005 1:47 PM (in response to manik)Why are you trying to solve problems that are already solved elsewhere?
Ignore me (on this thread), I thought this was the thread about MBeans.
NOTE TO SELF: Please engage brain before posting. -
8. Re: JBCACHE-106 - passing in options
manik Oct 27, 2005 1:52 PM (in response to manik)Had me wondering where else we had such a sol'n! :)
-
9. Re: JBCACHE-106 - passing in options
ben.wang Oct 27, 2005 2:02 PM (in response to manik)Gee, same here. :-)
Back to the subject, I prefer the Option class myself as well since we don't allow extension of Option anyway. (Or should we consider it for future customizable user-specific interceptors?)
The other thing is backward compatibility between say 1.3 and 1.3.1 (has a new option). But this is just the exception handling. -
10. Re: JBCACHE-106 - passing in options
adrian.brock Oct 27, 2005 2:29 PM (in response to manik)"The other thing is backward compatibility between say 1.3 and 1.3.1 (has a new option). But this is just the exception handling."
Obviously if you have a typed Option class rather than a key/value pair
public interface Option {}
public class TimeoutOption implements Option {}
It is going to fail early on classloading if somebody tries to use a version
where the option isn't supported.
Downside, maybe the user doesn't care if the option is ignored in an earlier version?
+1. I think there will always be only a limited number of options we allow callers to override,
Negative (if I understand correctly?), users can write their own for their own interceptors/backends. -
11. Re: JBCACHE-106 - passing in options
adrian.brock Oct 27, 2005 2:34 PM (in response to manik)Your other problem is that this is just invocation level overrides.
What about if people want to be more declaritive such as adding
overrides at
thread
transaction
application
etc. levels
cf:
http://docs.jboss.com/aop/1.3/aspect-framework/reference/en/html/implementing.html#impl-invocation4
Bill and I both agreed (when we discussed it in Boston earlier this year)
that metadata should be *typed* even if it is just for the same reasons that Java5 annotations
are typesafe.
This is as opposed to invocation attachments like transactions which is just payload. -
12. Re: JBCACHE-106 - passing in options
maxandersen Oct 28, 2005 2:41 AM (in response to manik)
I also like the Options interface/class.
I'm also wondering if some of these options would make a lot of sense to configure per FQCN hierachies ?
so that you could say this FQCN X and descendants would by default have optimistic locking while FQCN Y would not have optimistic locking.... the same would make sense (im my view) for how invalidation is defaulted.
Then hibernate could have a much simpler interface to JBossCache instead of us exposing treecache specific configuration - we don't do that for other cache providers. -
13. Re: JBCACHE-106 - passing in options
gavin.king Oct 28, 2005 5:57 AM (in response to manik)Options is fine by me, but we don't really care between the various possibilities, since we are hiding behind HB cache provider.
-
14. Re: JBCACHE-106 - passing in options
manik Oct 28, 2005 7:11 AM (in response to manik)"adrian@jboss.org" wrote:
Your other problem is that this is just invocation level overrides.
What about if people want to be more declaritive such as adding
overrides at
thread
transaction
application
etc. levels
This is a good point. In addition, what Max said about specifying overrides on a per-region basis.
Almost looks as though we may need something like:
1. A config file that defines global (application-wide) policy, which is treated as the default.
1.1. Regional sections to this config file that can override defaults on a per region basis. (a bit like apache's httpd.conf?)
2. Invocation-level overrides via Options.
2.1. Users could handle declarative overrides for thread or tx level characteristics by using some form of aspectisation (from AOP to interceptors), to manipulate an Options object which their final invocation code would use.