Scott and Alex have been working hard to make remote deployment possible in Resin from the server side. For the past couple of weeks, I’ve been working on making clients that can deploy your application to a running server. We have a number of vehicles in the works including an ant task, a maven plugin, and an Eclipse WTP deploy target. The interfaces to those are still under construction, as is the whole remote deploy framework, but I thought I’d give a quick preview of how to configure Resin and deploy to it.
Enabling the Resin administration service
The first step is to get Resin ready to accept remotely deployed apps. This is done by configuring the Resin remote admin service, including creating authorized accounts which will be able to use it. The configuration goes into our resin.xml:
- Resin 4.0 configuration file.
<sec:user name="admin.resin" password="password"/>
Notice that we’re using the new WebBeans IoC XML namespaces. The AdminAuthenticator specifies the users and passwords able to log into the RemoteAdminService. Also note that we configured the RemoteAdminService within a cluster. This is logical because once the distributed repository work gets completed, deploying a web app to a cluster member will cause that app to be distributed throughout the cluster.
Deploying from ant
Now from the client side, let’s see how to deploy a web app from ant. Assume we have the following project set up:
The index.jsp and web.xml will be bundled up appropriately into a .war file by our build file:
<property name="resin.home" value="/usr/local/share/resin"/>
<war destfile="foo.war" webxml="src/metadata/web.xml">
<resin-deploy server="127.0.0.1" port="8080"
warfile="foo.war" user="admin.resin" password="password"
Make sure you copy the resin-ant.jar to Resin root lib directory. (The jar will be available from here in the 4.0 directory.) The <resin-deploy> task is what actually does the work here. You’ll note the server and port (the port here is the HTTP port) specify an already running server. The user and password should match those set in the resin.xml. We also allow you to specify a commit message and version since you’re actually writing to a revision control system (GIT). You can also specify the virtual host and you need to specify the warfile you’re deploying. If you’ve got your Resin set up to do dependency checking on a regular interval (you probably do unless you explicitly disabled this), the web app will appear immediately when you browse to the /foo page.
Deploying from Maven
Maven is a bit slicker than Ant for this purpose. Start out by creating an empty war project:
Now edit my-webapp/pom.xml to look like the following:
<name>my-webapp Maven Webapp</name>
Note the configuration of the plugin here is a bit less verbose. We are able to infer the context root and war file path from the maven context. The only properties specified are the user and password. The default server, port, and host are 127.0.0.1, 8080, and default. The other nice thing about maven is that you don’t have to specify where the plugin is or download it. It will be pulled down from our repository at runtime.
To compile and deploy the project, just type:
In Part 2, I’ll discuss deployment from the Eclipse plugin. It’s a bit big for this post because of all the screenshots, so I decided to break it into its own.