-
Notifications
You must be signed in to change notification settings - Fork 108
Wiring JOSS to Spring
In your Spring application context (ie, probably application-context.xml), you need the following beans:
<bean id="cloudConfig" class="nl.tweeenveertig.openstack.client.factory.AccountConfig">
<property name="tenant" value="name-of-your-tenant"/>
<property name="username" value="username"/>
<property name="password" value="password"/>
<property name="authUrl" value="http://url.where.you.authenticate"/>
<property name="mock" value="false"/>
<property name="mockPublicUrl" value="http://localhost:8080/images"/> <!-- v0.7.0+ -->
</bean>
<bean id="cloudFactory" class="nl.tweeenveertig.openstack.client.factory.AccountFactory">
<property name="config" ref="cloudConfig"/>
</bean>
<bean id="cloudAccount" factory-bean="cloudFactory" factory-method="createAccount"/>
The AccountConfig contains all the information needed to authenticate against the ObjectStore. JOSS will use username, password and tenant to authenticate against the authentication URL. On success, it will gain access to the authentication token and the URLs to send requests to.
The mock parameter determines whether the real implementation (ie, actual access to the ObjectStore) or the mock implementation (ie, in-memory simulated ObjectStore) will be used. If you mock JOSS, you can also pass your own public URL. This URL will be used as the prefix to your content. One usage for this could be that you set up your own controller to access content in mock mode.
AccountFactory is the bean that will create the Account instance. Its method createAccount
will be called to actually do that.
Of course, it's also possible to wire your config bean using JNDI:
<jee:jndi-lookup id="cloudConfig" jndi-name="some-path/cloud-config"
expected-type="nl.tweeenveertig.openstack.client.factory.AccountConfig" />
This is especially sensible if you have multiple environments where you deploy your application.
In your code, you just make sure you have access to the "cloudAccount" bean. You could use @Autowired, for example.
@Autowired
private Account account;
The account bean is meant for long-living web applications. The bean will make use of the same token for as long as possible. When the authentication token expires, it is capable of automatically re-authenticating itself.
If you do not want to use the standard HttpClient implementation that JOSS instantiates, you can roll your own.
<bean id="httpClient" class="org.apache.http.impl.client.DefaultHttpClient">
<constructor-arg>
<bean class="org.apache.http.impl.conn.PoolingClientConnectionManager">
<property name="maxTotal" value="50"/>
<property name="defaultMaxPerRoute" value="25"/>
</bean>
</constructor-arg>
</bean>
<bean id="cloudFactory" class="nl.tweeenveertig.openstack.client.factory.AccountFactory">
<property name="config" ref="cloudConfig"/>
<property name="httpClient" ref="httpClient"/>
</bean>
It is possible to turn off the automatic reauthentication in case you want to be in control of that proces.
<bean id="cloudFactory" class="nl.tweeenveertig.openstack.client.factory.AccountFactory">
<property name="config" ref="cloudConfig"/>
<property name="allowReauthenticate" value="false"/>
</bean>
Account, Container and StoredObject all lazy-load their metadata and stick to that metadata once it has been loaded. Though it is possible to force a refresh through the reload
method, you can also disable caching entirely.
<bean id="cloudFactory" class="nl.tweeenveertig.openstack.client.factory.AccountFactory">
<property name="config" ref="cloudConfig"/>
<property name="allowCaching" value="false"/>
</bean>
The consequence of this operation is that for every getter call on an entity, a HTTP HEAD call is made to the ObjectStore. It's your call.