Sure, I'm open to suggestions. Basically I think we've discussed 1) Global Setting 2) canHandle() returns an int 3) Strategy has an enum type assigned
I'm open to all three, I don't have much vested interest in this. Darren On Fri, Oct 4, 2013 at 3:00 PM, SuichII, Christopher <chris.su...@netapp.com> wrote: > Well, it seems OK, but I think we should keep on discussing our options. One > concern I have with the global config approach is that it adds manual steps > for 'installing' extensions. Each extension must have installation > instructions to indicate which global configurations it must be included in > and where in that list it should be put (and of course, many extension are > going to say that they should be at the front of the list). > > -Chris > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 4, 2013, at 12:12 PM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > >> On 10/04/2013 11:58 AM, SuichII, Christopher wrote: >>> Darren, >>> >>> I think one of the benefits of allowing the priority to be specified in the >>> xml is that it can be configured after deployment. If for some reason two >>> strategies or providers conflict, then their priorities can be changed in >>> XML to resolve the conflict. I believe the Spring @Order annotation an be >>> specified in XML, not just as an annotation. >>> >>> -Chris >>> >> >> I would *prefer* extensions to be order independent, but if we determine >> they are order dependant, then that is fine too. So if we conclude that the >> simplest way to address this is to order the Strategies based on >> configuration, then I will add an ordering "global configuration" as >> described at >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions. >> >> Does the order configuration setting approach seem fine? >> >> Darren >
