Automatic deployment - directly from repository

[BernhardKraus]

Hi all,

reading the documentation I found information about deploying a new version of an artefact to the dm server using the pickup dir or the tool suite. My design approach is a little bit different, because the the appservers here are distributed and not always up. However the idea is to have a repository (e.g. Maven Archiva), to store the releases. If a new release is published to the repository, the application (itself) or (the distributed) appserver should be able to install the latest release automatically.

E.g. release_1.2.3.war is currently deployed. If a new release is deployed to the Archiva repository, (1.2.4), the existing WAR should be replaced.

Is there an out-of-the-box solution for that? How can I add this feature to my existing application?

Kind regards

Bernhard

[Glyn Normington]

There is no out of the box support for this use case, but in dm Server 2.0 I think you can use the new repository support to satisfy the requirement.

Let's assume there is an appserver dm Server instance configured with a repository chain consisting of a local repository and a hosted repository. In the appserver configuration, you can set a polling interval (in seconds using the <repo-name>.indexRefreshInterval property in the repository.properties file in the appserver's config directory - note we recently rebased our configuration mechanism on OSGi ConfigurationAdmin) which the appserver uses to synchronise its index with that of the hosted repository. The overhead of polling when there hasn't been an update is very small - essentially we send a HTTP get to the hosted repository and get back a 304 (NOT MODIFIED) response. So the polling interval can be set relatively small.

Then you need to write an application, which will run on the appserver and poll the repository mbean. When a new version of the WAR is added to the hosted repository and the appserver has polled and updated its index, the mbean will return the new version in the result of the call to the repository mbean. The application can then undeploy the old WAR and deploy the new WAR, using for example the deployer mbean.

There is one mbean per repository in the repository chain, so it is necessary to poll the mbean for the hosted repository. That mbean has name "com.springsource.server:type=Repository,name=host ed-repository". The attribute AllArtifactDescriptorSummaries returns short descriptions (type, name, and version) for all the artifacts in the repository.

It should be possible to get a proof of concept working with the latest nightly build of dm Server 2.0. I would then welcome any suggestions you might have for functional improvements if there are any major limitations in this approach.

How does that sound?

[BernhardKraus]

Hi Glyn,

sounds good - thank you. We used the 1.0.2 release for evaluation, but we can still switch to the latest release. If the communication to the remote repository is handled by a repository mbean, there is no need to for us to implement our own remote repository access bean. This seems to be the solution for our biggest problem ;-)

Where can I find information about Deployer and Repository mbean?

Kind regards

Bernhard

[Glyn Normington]

Hi Bernhard

sounds good - thank you. We used the 1.0.2 release for evaluation, but we can still switch to the latest release. If the communication to the remote repository is handled by a repository mbean, there is no need to for us to implement our own remote repository access bean. This seems to be the solution for our biggest problem ;-)

Sounds good.

Where can I find information about Deployer and Repository mbean?

Please start with the Deployer and RepositoryInfo mbean interfaces and if anything is unclear, post back here.

[BernhardKraus]

Thank you Glyn!