main website home
  • About this blog

    This blog features updates, opinions, and technical notes from Caucho engineers about Caucho products, the enterprise Java industry, and PHP. Caucho Technology is the creator of the Resin Application Server and the Quercus PHP in Java engine. A leader in Java performance since 1998, Caucho is a Sun JavaEE licensee with over 9000 customers worldwide.
  • Tags

    ajaxworld bam candi cdi cloud cluster comet configuration deploy devoxx eclipse ejb embedded flash flex google app engine hessian hmtp ioc java ee 6 javaone javazone jms messaging newsletter nyjug osgi php pomegranate quercus resin resin 4.0 REST servlet sfjug silicon valley code camp spring testing training tssjs watchdog webbeans web profile websockets wordpress
  • Meta

    • Register
    • Log in
    • Entries RSS
    • Comments RSS
    • WordPress.org
« Join us on Facebook!
Friday Meeting Summary, Jan 23 »

Remote deploy in Resin, Part 1

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.
  –>

<resin xmlns="http://caucho.com/ns/resin"
       xmlns:resin="http://caucho.com/ns/resin/core"
       xmlns:admin="urn:java:com.caucho.admin"
       xmlns:sec="urn:java:com.caucho.security">

  <sec:AdminAuthenticator password-digest="none">
    <sec:user name="admin.resin" password="password"/>
  </sec:AdminAuthenticator>
…

  <cluster id="app-tier">
    <admin:RemoteAdminService/>
…

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:

build.xml
src
src/jsp
src/jsp/index.jsp
src/metadata
src/metadata/web.xml

The index.jsp and web.xml will be bundled up appropriately into a .war file by our build file:

<project name="foo" default="compile" basedir=".">
  <property name="resin.home" value="/usr/local/share/resin"/>

  <target name="compile">
    <taskdef name="resin-deploy"
             classname="com.caucho.ant.ResinDeploy">

      <classpath>
        <fileset dir="${resin.home}">
          <include name="lib/*.jar"/>
        </fileset>
      </classpath>
    </taskdef>

    <war destfile="foo.war" webxml="src/metadata/web.xml">
      <fileset dir="src/jsp"/>
    </war>

    <resin-deploy server="127.0.0.1" port="8080"
                  warfile="foo.war" user="admin.resin" password="password"
                  commitmessage="initial commit"
                  version="0.1" virtualhost="default"/>

  </target>
</project>

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:

mvn archetype:create \
-DarchetypeGroupId=org.apache.maven.archetypes \
-DarchetypeArtifactId=maven-archetype-webapp \
-DgroupId=com.mycompany.app \
-DartifactId=my-webapp

Now edit my-webapp/pom.xml to look like the following:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-webapp</artifactId>
  <packaging>war</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>my-webapp Maven Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <pluginRepositories>
    <pluginRepository>
      <id>caucho</id>
      <name>Caucho</name>
      <url>http://caucho.com/m2</url>
    </pluginRepository>
  </pluginRepositories>

  <build>
    <finalName>my-webapp</finalName>
    <plugins>
      <plugin>
        <groupId>com.caucho</groupId>
        <artifactId>resin-maven-plugin</artifactId>
        <version>4.0-SNAPSHOT</version>
        <configuration>
          <user>admin.resin</user>
          <password>password</password>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

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:

mvn resin:deploy

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.

Tags: ant, eclipse, maven, resin 4.0

This entry was posted on Thursday, January 22nd, 2009 at 11:55 pm and is filed under Engineering. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Remote deploy in Resin, Part 1”

  1. stbu Says:
    January 23rd, 2009 at 11:24 am

    Sounds very interesting, Emil. Is web-app versioning also supported in this context, e.g. to update the already deployed foo-1.0.war on /foo with foo-1.1.war?

  2. ferg Says:
    January 26th, 2009 at 10:41 am

    Yes, the remote deploy is expanded just like a .war file, so you can upload foo-1.1.war and it will deploy just as if you’d dropped in a foo-1.1.war in the webapps directory.

Leave a Reply

You must be logged in to post a comment.


Caucho Technology is proudly powered by WordPress and Quercus®
Entries (RSS) and Comments (RSS).

  • HOME |
  • CONTACT US |
  • DOCUMENTATION |
  • BLOG |
  • WIKI 4 |
  • WIKI 3 |
  • Resin: Java Application Server
Copyright (c) 1998-2012 Caucho Technology, Inc. All rights reserved.
caucho® , resin® and quercus® are registered trademarks of Caucho Technology, Inc.
resin® is a cloud optimized, java® application server that supports the java ee webprofile ®