1 2 Previous Next 22 Replies Latest reply on Nov 16, 2005 12:22 PM by manik

    JBCACHE-106 - passing in options

    manik


      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).

      Would people prefer a Map of options?

      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. Re: JBCACHE-106 - passing in options
          belaban

           

          "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

            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

              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

                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

                  varargs is just syntatic suger over:

                  public void doSomething(Object[] parameters)

                  • 6. Re: JBCACHE-106 - passing in options

                    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

                       

                      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

                        Had me wondering where else we had such a sol'n! :)

                        • 9. Re: JBCACHE-106 - passing in options

                          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

                            "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

                              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


                                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

                                  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

                                     

                                    "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.



                                    1 2 Previous Next