cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate Gordon <nate.gor...@appcore.com>
Subject Re: CloudStack 4.3+ Plugins
Date Thu, 24 Apr 2014 22:02:05 GMT
With spring you can externalize values like this in a properties file. You
can then use classpath loading of the properties file in your spring xml
which allows you to have a properties file in your jar that provides sane
defaults, and a properties file in the WEB-INF/classes folder that
overrides it. You can check out the config at:
http://docs.spring.io/spring/docs/3.2.8.RELEASE/spring-framework-reference/htmlsingle/#beans-factory-placeholderconfigurer

We are doing something similar to configure some custom plugins we are
working on, but with groovy and spring java config. For example something
like this (I didn't even remotely test this example conversion for syntax
or typos):

context.xml:

<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
  <property name="locations" value="classpath:com/foo/myplugin.properties"/>
</bean>
<bean id="elastistorDataStoreProvider"
 class="org.apache.cloudstack.storage.datastore.provider.
ElastistorPrimaryDataStoreProvider">
        <property name="esmanagementip" value="${myplugin.esmanagementip}"/>
        <property name="esapikey" value="${myplugin.esapikey}"/>
        <property name="esaccountid" value="${myplugin.esaccountid}"/>
        <property name="espoolid" value="${myplugin.espoolid}"/>
        <property name="esdefaultgateway" value="
${myplugin.esdefaultgateway}"/>
        <property name="essubnet" value="${myplugin.essubnet}"/>
        <property name="estntinterface" value="${myplugin.estntinerface}"/>
  </bean>

myplugin.properties:
myplugin.esmanagementip=10.10.171.180
...



On Thu, Apr 24, 2014 at 12:34 AM, Punith S <punith.s@cloudbyte.com> wrote:

> hi,
>
> its good to have privately modularized context for plugins, but how do we
> inject the required variables from the component context after building the
> jars in 4.3 ?
> in 4.2 i used to inject the required params for my plugin from the
> componentcontext.xml after building the jars. so that params values can be
> changed at any point of time.
> all you need to do was to just restart the management server.
> ref - <bean id="elastistorDataStoreProvider"
>
>  class="org.apache.cloudstack.storage.datastore.provider.ElastistorPrimaryDataStoreProvider">
>         <property name="esmanagementip" value="10.10.171.180"/>
>         <property name="esapikey"
>
> value="PubSInZaCji8hrRfOsCxgbug2I2k_sRJ0i2a9qmAzZIiCTcFPmZelzx6uNK9TYgqkdohCmq1L2J9eYmUe9YO6A"/>
>         <property name="esaccountid"
> value="9e9f67d5-e06f-4d63-a0b8-e7255cba84b8"/>
>         <property name="espoolid"
> value="d2d15d11-0f06-3426-a097-3e6e8b36f85c"/>
>         <property name="esdefaultgateway" value="10.10.1.1"/>
>         <property name="essubnet" value="8"/>
>         <property name="estntinterface" value="em0"/>
>   </bean>
>
> but in 4.3 i'm not able to access my context.xml for injecting param values
> once i build my jars. !!
> any workaround available to do this ?
>
> thanks.
>
>
> On Thu, Apr 24, 2014 at 12:34 AM, Chris Suich <csuich2@gmail.com> wrote:
>
> > Hey Matt,
> >
> > Your correct in seeing that some improvements were made in 4.3 to
> > support more modularized plugins. This wiki page and its two child
> > pages should help you get started:
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modularize+Spring
> >
> > You no longer NEED to put your commands in the commands.properties.in
> > file as they can be specified in the API annotation now (they can be
> > put in the file to allow users to white/blacklist the file per use
> > role if they desire). Each module can also specify its own application
> > context so that everything is privately modularized.
> >
> > Take a look at the SolidFire storage plugin. That module is using the
> > new form of Spring extensions.
> >
> > -Chris
> >
> > On Wed, Apr 23, 2014 at 10:00 AM, Matt Spurlin <matt.spurlin@appcore.com
> >
> > wrote:
> > > In version 4.2 and below to get a plugin to work, I was adding a
> > dependency in the pom.xml of the Client project and modifying
> > applicationContext.xml.inand commands.properties.in. 4.3 appears to have
> > introduces discoverable plugins. What needs to be done differently in
> order
> > to take advantage of this?
> > > Thank you for your time,
> > > Matt
> >
> >
> >
> > --
> > Chris Suich
> > 919-334-8193
> > csuich2@gmail.com
> >
>
>
>
> --
> regards,
>
> punith s
> cloudbyte.com
>



-- 


*Nate Gordon*Director of Technology | Appcore - the business of cloud
computing®

Office +1.800.735.7104  |  Direct +1.515.612.7787
nate.gordon@appcore.com  |  www.appcore.com

----------------------------------------------------------------------

The information in this message is intended for the named recipients only.
It may contain information that is privileged, confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution, or the taking
of any action in reliance on the contents of this message is strictly
prohibited. If you have received this e-mail in error, do not print it or
disseminate it or its contents. In such event, please notify the sender by
return e-mail and delete the e-mail file immediately thereafter. Thank you.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message