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 -- Chris Suich chris.su...@netapp.com NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Oct 4, 2013, at 10:36 AM, Edison Su <edison...@citrix.com> wrote: > > >> -----Original Message----- >> From: SuichII, Christopher [mailto:chris.su...@netapp.com] >> Sent: Thursday, October 03, 2013 9:02 PM >> To: <dev@cloudstack.apache.org> >> Subject: Re: [PROPOSAL] Modularize Spring >> >> Sure - I could see that working. Anyone have thoughts whether an enum >> could be used instead of an integer? That way we can provide categories or a >> well defined scale (like 0-5)? If we give them free range of 1-100 (or any >> integer range), I imagine people will likely go to the extremes and just use >> 0 >> for can't handle, 1 for low priority (default) and 100 for high priority >> (storage >> providers). We still have the problem of handling conflicts, or implementers >> who return the same value. However, I'm not sure there is much we can do >> beyond selecting the first implementation that we come across with the >> highest priority. We should document and suggest that implementations >> ensure their canHandle() method is as intelligent as possible and only takes >> control of operations they are truly authorities on. > > How to use the way spring 4.0 did: > https://jira.springsource.org/browse/SPR-5574? > http://stackoverflow.com/questions/16967971/spring-ordered-list-of-beans > Add order in bean. > >> >> -Chris >> -- >> Chris Suich >> chris.su...@netapp.com >> NetApp Software Engineer >> Data Center Platforms - Cloud Solutions >> Citrix, Cisco & Red Hat >> >> On Oct 3, 2013, at 7:44 PM, Darren Shepherd <darren.s.sheph...@gmail.com> >> wrote: >> >>> Could it be just as simple as the canhandle() returns an int and not >>> Boolean. >> So the ancient would return 1 but if the netapp matches it returns 100. If >> it >> does not handle at all you return -1. This effectively gives you >> prioritization. >> So the calling code would still loop through all strategies each time >> looking for >> the best match. I don't want the priority to be determined at load time as >> that is less flexible. >>> >>> Darren >>> >>>> On Oct 3, 2013, at 5:42 PM, "SuichII, Christopher" >> <chris.su...@netapp.com> wrote: >>>> >>>> Thanks for the quick reply. >>>> >>>> After talking with Edison, I think what we could do is allow the strategies >> to either specify a priority or 'type' and then order them by that when they >> are loaded. For example, we could have an enum of types like 'PLUGIN, >> HYPERVISOR and DEFAULT' so that we can make sure plugins are asked >> canHandle() first, then hypervisor implementations, then finally resort to >> the >> default/ancient implementation. This 'type' or 'category' could be specified >> as a bean parameter or as part of the strategy/provider interface. Any >> thoughts on which are better? >>>> >>>> The problem with just making canHandle() more intelligent is that we do >> need some kind of ordering. Ideally, the non-default implementations >> should be asked first, then fall back onto the stock implementations. You saw >> the problem yourself - the XenServerSnapshotStrategy just says it will handle >> all requests, so if a non-standard strategy wants to be given a chance, it >> must >> be asked before the hypervisor or ancient implementation. >>>> >>>> Alternatively if this matches the same usage of the global configuration >> ordering system, we could add in the storage subsystem strategies and >> providers. >>>> >>>> The reason for log4j changes is that we may want to enable a different >> level of verbosity by default. Our support organization likes to have very >> verbose logs to assist them in triaging support issues. The lowest level >> log4j >> categories are 'com.cloud', 'org' and 'net' and those are set to DEBUG and >> INFO. Even if we add a line for 'com', the default value should not be >> 'TRACE' >> like we would like ours to be. I'm not all that great with log4j, though, so >> maybe I'm missing a simpler solution. >>>> >>>> I'll try to keep an eye on the commands.properties/rbac stuff - that is >> good to know. >>>> >>>> Thanks, >>>> Chris >>>> -- >>>> Chris Suich >>>> chris.su...@netapp.com >>>> NetApp Software Engineer >>>> Data Center Platforms - Cloud Solutions Citrix, Cisco & Red Hat >>>> >>>>> On Oct 3, 2013, at 4:30 PM, Darren Shepherd >> <darren.s.sheph...@gmail.com> wrote: >>>>> >>>>> I forgot to mention about canHandle() ordering. For extensions, it >>>>> should be preferred that we do not rely on loaded or configured order. >>>>> The canHandle() implementation should assume that they're may be any >>>>> order. So having said that, I looked at XenServerSnapshotStrategy >>>>> and its canHandle() is brilliantly implemented as "return true;" >>>>> >>>>> Can we look at making the strategies order independent and not >>>>> having another order configuration parameter? >>>>> >>>>> Darren >>>>> >>>>> On Thu, Oct 3, 2013 at 4:26 PM, Darren Shepherd >>>>> <darren.s.sheph...@gmail.com> wrote: >>>>>> Chris, >>>>>> >>>>>> I've updated the wiki [1]. Copying from the wiki >>>>>> >>>>>> "Extensions are automatically discovered based on the interfaces >>>>>> they implement and which module is their parent. For example, if >>>>>> you place a storage extension in a child module of the network >>>>>> module, it will not be discovered. Additionally, depending on the >>>>>> extension, the ordering may be important in how they extension is >>>>>> used. For the extensions that ordering is important there is also a >>>>>> "Global Configuration" setting for the ordering. The value of the >>>>>> setting is a comma seperated list like >>>>>> SHA256SALT,MD5,LDAP,PLAINTEXT. The values are the names of the >>>>>> extension. The name will be the result of getName(), if the bean >>>>>> implements the Named interface, or the sort class name (ie >> getClass().getSimpleName())." >>>>>> >>>>>> I setup all the extensible types based on what was in >>>>>> componentContext.xml and also trial an error. The types you have >>>>>> mentioned were not in componetContext.xml so I missed them. It >>>>>> works today, but is not properly extensible. I will update the >>>>>> configuration and wiki today. >>>>>> >>>>>> I've haven't made progress on the commands.properties as I realized >>>>>> it will overlap with the rbac work being done. I will start a >>>>>> thread regarding that so maybe it will be address in the rbac work. >>>>>> >>>>>> Regarding log4j. First, why do you have to change that? >>>>>> Regardless, at the end of the day you are limited to whatever log4j can >> provide. >>>>>> So log4j AFAIK does not support multiple log4j config files so the >>>>>> best we can do is allow somebody to supply a different log4j config >>>>>> file and configure cloudstack to use that. One of the things I >>>>>> don't particularily like is that ACS forces log4j to its own >>>>>> configuration file and will not allow the regular log4j config >>>>>> discovery. So what I could do is add a JVM property like >>>>>> -Dcloudstack.log4jstandardconfig that will disable the ACS behavior >>>>>> of configuring log4j and then you can use the log4j standard approach >> [2]. >>>>>> >>>>>> Darren >>>>>> >>>>>> [1] >>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions >>>>>> [2] http://logging.apache.org/log4j/1.2/manual.html >>>>>> >>>>>> On Thu, Oct 3, 2013 at 3:29 PM, SuichII, Christopher >>>>>> <chris.su...@netapp.com> wrote: >>>>>>> Darren, >>>>>>> >>>>>>> I read through this thread and your docs on the wiki, but I'd >> appreciate it if you could answer a couple questions for me: >>>>>>> >>>>>>> -When creating an extension, such as a DataStoreProvider, those >> items are currently added into the list of providers for the appropriate >> bean, >> such as: >>>>>>> <bean id="dataStoreProviderManager" >>>>>>> >>>>>>> class="org.apache.cloudstack.storage.datastore.provider.DataStoreP >>>>>>> roviderManagerImpl"> >>>>>>> <property name="providers"> >>>>>>> <list merge="true"> >>>>>>> <ref bean="cloudStackPrimaryDataStoreProviderImpl"/> >>>>>>> <ref local="cloudStackImageStoreProviderImpl"/> >>>>>>> <ref local="s3ImageStoreProviderImpl"/> >>>>>>> <ref local="swiftImageStoreProviderImpl"/> >>>>>>> <ref local="solidFireDataStoreProvider"/> >>>>>>> </list> >>>>>>> </property> >>>>>>> </bean> >>>>>>> >>>>>>> So, how do we add our bean to that list? >>>>>>> >>>>>>> -There are a number of extensions that are not currently listed, such >> as DataMotionStrategy, SnapshotStrategy, etc. Is it a problem that those are >> omitted from >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions? >>>>>>> >>>>>>> -I know somewhere in this thread you talked about the order of >> beans, but can you document how the ordering or precedence works in the >> wiki? For example, if I create a DataMotionStrategy, how do I ensure that my >> strategy's canHandle() method is invoked before the >> AncientDataStoreStrategy? >>>>>>> >>>>>>> -Is there any progress on modularizing commands.properties and the >> log4j configuration? >>>>>>> >>>>>>> Thanks, >>>>>>> Chris >>>>>>> -- >>>>>>> Chris Suich >>>>>>> chris.su...@netapp.com<mailto:chris.su...@netapp.com> >>>>>>> NetApp Software Engineer >>>>>>> Data Center Platforms - Cloud Solutions Citrix, Cisco & Red Hat >>>> >
