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