Latest revision as of 01:08, 6 February 2010

[edit] Migrating to Resin from WebLogic

[edit] Who should migrate?

Wondering if Resin is right for you and your application? The following table can give some guidance based on your current application or development environment.

[edit] Configuration architecture

Resin offers many advanced features and exceptional performance in a lightweight container. Users migrating from WebLogic to Resin will initially find the workflow associated with development and administration differs greatly between the two products. However Resin users tend to find configuration and development to be very natural and efficient, especially compared with other application servers.

[edit] Managing configuration

[edit] Single Server configuration

Resin's configuration is based on straightforward, compact, and uncluttered XML files. The contents of these XML files represents the operational configuration of Resin. If these configuration files are changed, Resin can detect the change and restart either a web application, a virtual host, or the entire server so that the internal configuration matches that of the file. WebLogic, on the other hand, maintains its configuration via a web-based administration console or command line tool. In fact, WebLogic's configuration tools actually write a file called "config.xml" which serves a similar purpose as Resin's XML file. The advantage of using Resin's approach to configuration is that you have direct control over server operation without relying on tools which may obscure or confuse the underlying configuration file.

[edit] Multiple Server configuration and organization

Resin's configuration across multiple servers is also handled differently than WebLogic. In Resin, each server uses the XML configuration from the file system. In contrast, WebLogic specifies an administration server that manages configuration for all of the servers in a WebLogic "Domain". In this aspect, Resin has reduced architectural overhead, but may require external management techniques for distributing configuration to all servers in a deployment such as file system synchronization or a networked file system.

WebLogic Configuration	Resin Configuration

[edit] Comparative Directory Layout

In addition to XML configuration, Resin also uses directory layout and the state maintained on the file system to configure application-related aspects of the server, such as application deployment, virtual hosts, and library management. This approach allows developers and administrators to see the state of a Resin applications simply by looking at the XML configuration and the file system. Conversely, to update Resin's applications or virtual hosts, users may simply create directories and copy files. Resin is able to use common directory structures (such as that of Apache HTTPd and Apache Tomcat) to migrate legacy applications.

WebLogic's directory structure [1] is more centralized than Resin's and is more closely managed by the application server. In contrast to Resin's application-oriented directory structure, WebLogic's directories reflect the state of the WebLogic Domains and servers. Application management is handled via a web console or command line tool; direct file system manipulation of applications is not recommended (except in the case of the "autodeploy" mechanism for non-production servers). WebLogic also uses a "Server Root" directory to store runtime data associated with each server. Depending on the server type, this directory is located in different places and has a different structure. Resin stores runtime data as well, but the directory structure used for this purpose is identical on all servers.

[edit] Starting and Stopping Resin compared to WebLogic

Resin (beginning with version 3.1) uses a manager, called the Resin Watchdog, to start, stop, and monitor the actual JVM process for Resin. The Watchdog itself is another Java program, so each server running Resin uses two processes for improved reliability. The Watchdog's responsibilities are limited to process management; it does not run the Resin administration console or perform other advanced features. Resin's Watchdog uses the same configuration files as the actual Resin server and it is in charge of launching the JVM for Resin. Instead of creating shell scripts to configure options such as JVM parameters, Resin users simply have all of their startup configuration located in a single file.

Because Resin does not have different types of servers (e.g. administration versus managed), the analogous infrastructure of WebLogic (e.g. node managers, etc.) [2] [3] does not apply. WebLogic users typically create startup scripts for their server to manage aspects of startup such as the classpath, JVM arguments, and override configuration. Resin manages all of these configuration options in its resin.xml file.

[edit] Application Deployment

[edit] Automatic (file system-based deployment)

Resin uses a file system-based approach to deployment, meaning that .war files or exploded applications can be copied directly to a live, automatic deployment directory for production. This approach is similar, though not identical to the "autodeploy" directory concept in WebLogic. In Resin, .war and .ear files are exploded into full directories when detected by the application server. Thus every application has an associated directory that is accessible by the user. This directory represents the live state of an application, so modifications to files are immediately visible both in development and production. If the application's deployment descriptor (e.g. web.xml or resin-web.xml) are changed, Resin detects the change and restarts the application automatically.

WebLogic by comparison does not explode .war and .ear files into a live, user-accessible directory and care must be taken not to delete the .war or .ear files while the server is not running. To make changes to an application in an exploded directory, WebLogic users must create a file called REDEPLOY within the application to alert the application server to restart the application. This step is not necessary in Resin.

[edit] Comparative File System Paths in Resin versus WebLogic

Both Resin and WebLogic have "root directories", but they refer to different concepts and file system layouts. Resin's root directory is the content root in which all application files are stored. Typically on Unix or Linux systems, this directory is /var/www and on Windows it is C:\www. To deploy an application to Resin, the live deployment directory is $RESIN_ROOT/webapps. Simply copy a .war file or exploded application directory to this directory and the application will be deployed.

[edit] Distributed Deployment

Starting in version 4.0, Resin features a distributed application deployment mechanism that enables users to

• Distribute applications across all Resin servers with a single step
• Migrate applications to new servers automatically on startup
• Manage application versions without interrupting the user experience
• Verify applications in the same environment as live applications before going live (staging)

This feature of Resin 4.0 is based on Git technology which provides high performance and easy-of-use for new users and transparency and low-level access for more advanced users.

[edit] Converting weblogic.Deployer commands to task-based commands using Maven

WebLogic has many analogous features to Resin 4.0's distributed deploy mechanism and many of the commands used in WebLogic can be converted to use Resin-based tools with similar semantics. Resin provides plugins for both Ant and Maven2 which allow integration directly with two of the most popular Java build environments. The Maven2 plugin is most directly analogous to the weblogic.Deployer command, so we will limit our discussion to that tool in this document.

The first step is to add the Caucho Resin plugin to your Maven2 pom.xml file for your project. This example shows a simple pom.xml file:

 <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.test</groupId>
   <artifactId>test</artifactId>
   <packaging>war</packaging>
   <version>1.0-SNAPSHOT</version>
   <name>test Maven Webapp</name>
   <url>http://maven.apache.org</url>
   <dependencies>
   </dependencies>
   <pluginRepositories>
     <pluginRepository>
       <snapshots>
         <enabled>true</enabled>
         <updatePolicy>always</updatePolicy>
         <checksumPolicy>ignore</checksumPolicy>
       </snapshots>
         <id>caucho</id>
         <name>Caucho</name>
         <url>http://caucho.com/m2-snapshot</url>
     </pluginRepository>
   </pluginRepositories>
       
   <build>
     <finalName>foo</finalName>
 
     <plugins>
       <plugin>
         <groupId>com.caucho</groupId>
         <artifactId>resin-maven-plugin</artifactId>
         <version>4.0.2</version>
         <configuration>
           <server>127.0.0.1</server>
           <port>80</port>
           <user>foo</user>
           <password>test</password>
         </configuration>
       </plugin>
     </plugins>
   </build>
 </project>

Notice the highlighted section of the plugin configuration. This section specifies one of the three core members of a Resin 4.0 cluster called a triad. For now, just think of this as the first configured server in the cluster. (More information on clustering is available below.) The address and HTTP port of the server are specified, as well as a user name and password. (Security related information will also be discussed in another section below.) This configuration is used for all the deployment related commands below.

This goal builds the war and uploads it to Resin, using the finalName ("foo" in this case) as the context root:

 mvn resin:upload-war

This is roughly analogous to the following weblogic.Deployer command:

java weblogic.Deployer -adminurl http://localhost:8080 -user foo
  -password test -deploy -targets server1,server2 myApp.war

Note that there is no equivalent of the WebLogic "targets" argument in Resin. This is because Resin automatically deploys applications throughout the cluster. In other words, Resin's view of clusters is that all servers within each cluster have the same applications. To partition applications among servers, you can set up multiple clusters.

[edit] WebLogic Side-By-Side versions and Resin application versioning

Both Resin and WebLogic have similar application versioning capabilities. When upgrading an application on a live site, users using the previous version of the application will continue to use that version so long as their sessions remain valid. New users will be directed to the newest version of the application. This feature allows a seamless transition on application version upgrades without affecting users. This is referred to as Side-By-Side Deployment for WebLogic and application versioning for Resin.

At the time of writing, no documentation to use WebLogic Side-by-Side versioning with the weblogic.Deployer command was found; the WebLogic administration console appears to be the main interface used to set versioning attributes. Thus the examples below simply show some basic interactions with Resin's Maven plugin to using versioning with an application:

To upload a version 1.0 of our "foo" application:

 mvn resin:upload-war -Dresin.version="1.0"

Upload version 2.0 of our "foo" application:

 mvn resin:upload-war -Dresin.version="2.0"

To query all versions of the webapp in the repository:

 mvn resin:query-tags -Dresin.version='.*

[edit] Application "staging"

Resin and WebLogic both use the term "staging" in application deployment, but the term refers to different concepts for each application server. For Resin, "staging" refers to a feature that allows users to test applications in a test bed environment identical to the production environment without going "live." Both applications and servers have a "stage," such as "default" or "preview." A server only serves applications with a stage matching its own. When deploying an application, the user can specify that an application is in the "default" stage, in which case the application is deployed on servers in the "default" stage. This stage is typically used for live, production deployments. Alternately the user can specify another stage such as "preview". There may be only one server in the cluster running in the "preview" stage behind a firewall, used to allow developers the chance to test the application in the same environment as the production servers. Once the developer is satisfied that this application is ready for production, its stage may be switched to "default" and deployed on the live servers.

WebLogic has a very different notion of "staging" in which applications are copied to servers first, then deployed only after all the application files have arrived at all servers. Resin's deployment mechanism always does this; applications are only started once they have been uploaded fully and are "tagged" in the Git repository.

[edit] Deployment Descriptors (weblogic.xml and resin-web.xml)

Both Resin and WebLogic have additional application deployment descriptors that provide functionality that goes beyond Java EE standards. In Resin, this descriptor is called resin-web.xml and in WebLogic it is called weblogic.xml. Both supplement web.xml and provide web application-specific configuration. Both descriptors allow customizing the session, security, logging, character set, and URL mapping policies. We'll look at each of these issues individually.

[edit] Session configuration

Resin can configure session behavior in resin-web.xml, though defaults for all applications can be set at the cluster or host levels. In Resin, the configuration for sessions is done by extending the <session-config> tag syntax. In WebLogic, these settings are configured via the <session-descriptor> tag in weblogic.xml. Below is a table showing the similar configuration items for each (when applicable) and any differences in behavior. Each item is an XML child tag of the respective configuration, unless otherwise specified.

[edit] Security Configuration

Resin 4.0 introduces a new framework to deal with authentication and authorization for web applications.[4] WebLogic manages principals in security realms, which are then mapped to roles which are compatible with the <security-constraint> mechanism of web.xml files.[5] Resin's framework can behave in the same way, but the preferred method of configuring authorization is to use Resin's framework rather than the web.xml <security-constraint>.

[edit] Authentication

Resin can authenticate users using JDBC, JAAS, LDAP, XML, or a custom method.[6] These methods can use users, passwords (including digested passwords), and roles extracted from these external sources. These authenticators can be configured in resin-web.xml or resin.xml and shared among web applications or isolated to a single application. WebLogic's equivalent configuration is performed through its administration console.

Below is an example of Resin's XML authenticator that may be configured in resin.xml or for individual webapps in the resin-web.xml. It is typically used for applications with a small number of privileged users, such as the Resin administration console.

    <security:XmlAuthenticator>
      <password-digest>md5-base64</password-digest>
      <user name='myuser' password='IXiMnz7P2cJU18MSJjKiaA=='>
        <role>user</role>
        <role>foo</role>
      </user>
    </security:XmlAuthenticator>

[edit] Authorization

WebLogic uses <security-constraints> in web.xml files at the application level. Resin supports this standard configuration, but also provides a robust and powerful alternative configuration model [7]. For example:

<web-app xmlns="http://caucho.com/ns/resin"
        xmlns:resin="urn:java:com.caucho.resin">
	
  <resin:Allow url-pattern="/admin/*">
    <resin:IfAddress name="192.168.17.0/24"/>
  </resin:Allow>

  <resin:Deny>
    <resin:IfNetwork>
       <resin:value>123.4.45.6</resin:value>
    </resin:IfNetwork>
  </resin:Deny>

</web-app>

This model can allow or deny requests based on roles, network origin, security of the connection (SSL), or even custom security constraints. The format aims to be more readable and extensible than the <security-constraint> model.

[edit] URL Mapping

In addition to the standard <servlet-mapping> facility, both Resin and WebLogic provide extended URL mapping capabilities. Resin contains a sophisticated XML-based URL mapping configuration, called Rewrite dispatch, which is capable of replacing facilities like Apache's mod_rewrite in many cases. WebLogic provides a facility which allows the user to implement a custom mapping as a Java class [8]. Resin's mechanism is extensible as well, but provides numerous XML configuration options out of the box.

As an example of a Resin rewrite configuration, the following dispatches all static and PHP files directly, but redirects all other requests to a central controller script, index.php:

<web-app xmlns="http://caucho.com/ns/resin"
        xmlns:resin="urn:java:com.caucho.resin">

  <resin:Dispatch regexp="\.(php|js|gif|png|css|html)$"/>

  <resin:Dispatch regexp="^" target="/index.php"/>

</web-app>

Both Resin and WebLogic have virtual path mapping abilities as well to remap file system directories to alternate URL paths. Resin's tag is <rewrite-real-path> and uses regular expressions to remap a target, while WebLogic's tag is <virtual-directory-mapping> and uses <servlet-mapping> style URL patterns.

[edit] Database connectivity

Resin provides JDBC connectivity to applications via pools, which are accessed either via JNDI reference or CanDI (JSR-299). Resin database pools can be configured on an application level using the resin-web.xml descriptor file. Configuring database pools in Resin is roughly analogous to JDBC Data Source Modules in WebLogic [9].

<jdbc-data-source xmlns="http://www.bea.com/ns/weblogic/91">
  <name>demo-database</name>

  <jdbc-driver-params>
    <url>jdbc:mysql:server://localhost:3306/demo</url>
    <driver-name>com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource</driver-name>
    <properties>
      <property>
        <name>user</name>
        <value>demo</value>
      </property>
      <property>
        <name>databaseName</name>
        <value>jdbc:mysql:server://localhost:3306/demo</value>
      </property>
    </properties>
    <password-encrypted>ABCDEFGxyz</password-encrypted>
  </jdbc-driver-params>

  <jdbc-connection-pool-params>
    <max-capacity>50</max-capacity>
    <test-connections-on-reserve>true</test-connections-on-reserve>
  </jdbc-connection-pool-params>
 
  <jdbc-data-source-params>
    <jndi-name>jdbc/demo</jndi-name> 
  </jdbc-data-source-params>
 
</jdbc-data-source>

<web-app xmlns="http://caucho.com/ns/resin">
 
  <database jndi-name='jdbc/demo'>
    <driver>
      <type>com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource</type>
      <url>jdbc:mysql://localhost:3306/demo</url>
      <user>demo</user>
      <password>demo</password>
    </driver>
    <ping>true</ping>
    <max-connections>50</max-connections>
  </database>

</web-app>

Given this example, below is a table of some of the most popular JDBC configuration options and their equivalents in Resin and WebLogic

[edit] Logging

Both Resin and WebLogic (since version 8.1 [10]) use java.util.logging facilities to handle logging. Resin uses java.util.logging for server-level messages and applications that use these facilities should be very portable across both application servers.

[edit] Log Levels

WebLogic's administration console and weblogic.Admin do not provide a way to set Logger levels; WebLogic users set levels via the Java API. These APIs are compatible with Resin, so existing code to perform this function will continue to work on Resin.

In addition to the Java API, Resin also features a way to set Logger levels through XML configuration. The following can be set in the top-level resin.xml file or in application-specific resin-web.xml files:

<logger name="com.example.myapp" level="fine"/>

Server-level logging is also set using this configuration on the "com.caucho" tree of Loggers.

[edit] Log files and rotation

Resin can have any number of log files, all with their own individual rotation schedules and parameters. Resin configures log files in resin.xml or even in individual resin-web.xml files. WebLogic's log configuration is handled in its administration console [11].

To configure a basic log file in Resin for all logs, you might use the following:

 <log-handler name="" level="all" path="stdout:"
              timestamp="[%y-%m-%d %H:%M:%S.%s] {%{thread}} "/>

In this special example, the path ("stdout:") is redirected to a file in the log directory specified on the command line when starting Resin. The name of the file incorporates the server name (e.g. /var/www/log/jvm-servername.log). All levels of log messages are written to the file from all sources.

To create a more selective log file that only logs fine-level (and higher) server messages and rotates when the log grows larger than 1MB, you might use the following:

 <log-handler name="com.caucho" level="fine" path="server.log"
              timestamp="[%y-%m-%d %H:%M:%S.%s] {%{thread}} " 
              rollover-size="1MB" />

Similarly rollovers based on a time period, the maximum number of rolled-over logs to keep, and log compression can be enabled using Resin's XML configuration.[12]

[edit] Converting Clustered deployments

Resin and WebLogic handle clustering very differently, but conversion to Resin is not difficult if you understand the goals of your original clustered deployment. Resin is capable of performing load balancing, request failover, session replication, and distributed application deployment with its clustering mechanism. The main differences between Resin and WebLogic clustering [13] are:

[edit] Session replication and Failover

Both Resin and WebLogic support HTTP/Servlet session replication. In Resin, sessions can be replicated on an application-by-application basis simply by setting the <use-persistent-store> tag in the application resin-web.xml descriptor:

  <web-app xmlns="http://caucho.com/ns/resin">
    <session-config>
      <use-persistent-store/>
    </session-config>
  </web-app>

Resin 4.0 makes the sessions available to any servers in the cluster, including those added dynamically at runtime to boost capacity. All sessions in Resin 4.0 are replicated on the Triad servers (first three servers) of the cluster. This replication scheme enables dynamically added servers to access session data and increase load capacity at will. The administrator of the cluster also only has to monitor these three servers to guarantee that no sessions will be lost.

WebLogic uses a secondary server replication approach in which each session has a primary server and another, secondary server in the cluster which replicates the session. This approach decentralizes the session management, but does not allow for dynamically adding servers at runtime, forces the administrator to monitor all servers actively, and allows session loss after any two servers in the cluster fail.[14]

[edit] WebLogic Replication groups compared with Resin triad configuration

WebLogic Replication groups allow fine-level control of session replication in a cluster. Each server can have a preferred replication group which is more likely to host the secondary backup of a session.[15] Resin's triad configuration can be viewed as a predefined replication group for each cluster, except that the administrator can be sure that all sessions will be backed up on the triad (rather than be more likely) and that each session will be backed up on all three servers instead of just one.

[edit] Load balancing: WebLogic Proxy plugins versus Resin load balancer

Resin and WebLogic both allow proxying and load balancing connections to a clustered application, but Resin offers advanced load balancing features that

• Enable dynamic server addition and removal at runtime
• Feature advanced metrics for determining which server can best handle a request
• Sticky sessions
• Allow sophisticated request-based redirection rules

WebLogic's proxying and load balancing is configured by using the HttpClusterServlet as an application on a WebLogic instance. Resin's proxying and load balancing is also implemented as a servlet and run on a Resin instance, but can be configured using Resin's advanced rewrite [16] mechanism that allows the administrator to craft custom redirection rules based on regular expressions applied to request URLs, methods, headers, and more.

The basic configuration for Resin's load balancing is to create a cluster of Resin instances that server as load balancers (often only one server is necessary for small to medium sized sites), then configure those servers to redirect requests to a second cluster hosting the application. For example,

<resin xmlns="http://caucho.com/ns/resin"
       xmlns:resin="urn:java:com.caucho.resin">

  <cluster id="app-tier">
    <server id="app-a" address="192.168.0.10" port="6800"/>
    <server id="app-b" address="192.168.0.11" port="6800"/>

    <host id="">
      <web-app id="" root-directory="webapps/ROOT"/>
    </host>
  </cluster>

  <cluster id="web-tier">
    <server id="web-a" address="192.168.0.1" port="6800">
      <http port="80"/>
    </server>

    <host id="">
      <web-app id="">
        <resin:LoadBalance regexp="" cluster="app-tier"/>
      </web-app>
    </host>
  </cluster>

</resin>

Here, there are two servers in the "app-tier" cluster and a single server in the "web-tier" cluster. The "web-tier" server directs all traffic to "app-tier" cluster, using load balancing and failover as necessary.

[edit] HTTP Configuration

Resin and WebLogic use similar concepts in configuring HTTP, though Resin uses its XML configuration whereas WebLogic uses its web console.

Resin's HTTP configuration is specified for each server, thus in the XML configuration, each <server> tag may have one or more <http> child tags. For example:

<server id="" address="127.0.0.1" port="6800">
  <http address="*" port="80"/>
 
  <user-name>www-data</user-name>
  <group-name>www-data</group-name>
</server>

The <http> tag can attach to specific IP addresses as well, so different ports may be used in case several interfaces are available on the server.

On Unix and Linux, binding to ports below 1024 requires a privileged user, but many administrators prefer running the server as a non-privileged user for security purposes. Both Resin and WebLogic are able to bind to privileged ports, then change to a non-privileged user before serving content. In the sample above, the existence of the <user-name> or <group-name> tags corresponds to the "weblogic.system.enableSetUID" and "weblogic.system.enableSetGID" WebLogic variables, respectively. The text of these tags corresponds to the "weblogic.system.nonPrivUser" and "weblogic.system.nonPrivGroup" variables, respectively.

[edit] Keepalive and other socket parameters

Both Resin and WebLogic are capable of supporting HTTP keep-alive. WebLogic configuration allows enabling keep-alives and setting the maximum idle duration of a connection. Resin allows setting these values as well as the maximum number of simultaneous connections and whether to use thread-based or select-based connection management. Thread-based connection management uses a thread for each keep-alive connection, even if the connection is not active. Select-based connection management allows the server to use fewer threads by only using them with active connections. This is a powerful feature of Resin that enables advanced features such as WebSockets and other event-based web techniques. The following example shows how these options are configured in Resin:

<server id="" address="127.0.0.1" port="6800">
  <http address="*" port="80"/>
 
  <keepalive-max>256<keepalive-max>
  <keepalive-timeout>10s<keepalive-timeout>
  <keepalive-select-enable>true<keepalive-select-enable>
</server>

[edit] SSL

Both Resin and WebLogic are capable of supporting SSL HTTP connections. In addition to Java-based (JSSE) SSL, Resin Professional also allows using OpenSSL for vastly improved performance through a JNI bridge. The following is an example of Resin's OpenSSL configuration:

<server id="" address="127.0.0.1" port="6800">
  <http address="*" port="80"/>
 
  <http address="*" port="443">
    <openssl>
      <certificate-file>keys/mycompany.crt</certificate-file>
      <certificate-key-file>keys/mycompany.key</certificate-key-file>
      <password>test123</password>
    </openssl>
  </http>
</server>

Using OpenSSL, Resin can also cache SSL sessions, using OpenSSL's internal caching features.

[edit] Integrating with other tools

[edit] Development tools

[edit] Eclipse

Resin features a development plugin for Eclipse based on the WTP framework. With this plugin, developers have all of the facilities of the WTP environment with the ability to deploy to Resin using a variety of file system and remote deployment options. The deployment options include:

• .war file (default) - the plugin builds a .war file of your project, then starts Resin and copies the .war to the live deploy directory.
• Temporary directory - the plugin builds a .war file of your project, then starts Resin and copies the .war to a temporary deploy directory.
• In-place - the plugin starts Resin, then points it to server your project directly out of the workspace.
• Hot-deploy - (Resin 4.0 only) the plugin builds a .war file of your project, then starts Resin and uses Resin's Git deployment functionality to deploy

The plugin also features built-in configuration files that are tuned for the development environment, but the user has the option of using any configuration file as well.

[edit] Embedding Resin

Resin allows the entire server to be embedded within another Java process, enabling easier testing and integration. This feature is available via a Java API and gives the calling Java code almost all of the capabilities of the Resin server (with the exception of the watchdog features).

[edit] Automated Testing

Automated testing frameworks such as JUnit can embed Resin to allow for application testing. Any application that can run in Resin, such as a JSP or PHP-based application, can be tested in these frameworks. For example, if the application contains the following PHP script:

<?php 
$a = $_GET["a"];
$b = $_GET["b"];

echo "$a + $b = " . ($a + $b); ?>

The JUnit test may look like the following:

package qa;

import org.junit.*;
import static org.junit.Assert.*;
import com.caucho.resin.*;

public class MyTest {
  private static ResinEmbed _resin;

  @BeforeClass
  public static void setup()
  {
    _resin = new ResinEmbed();
    WebAppEmbed webApp = new WebAppEmbed("/", "file:/tmp/caucho/qa/test");
    _resin.addWebApp(webApp);
    _resin.start();
  }

  @Test 
  public void test1plus1()
    throws java.io.IOException
  {
    assertEquals(_resin.request("GET /test.php?a=1&b=1"), "1 + 1 = 2");
  }

  @Test 
  public void test1plus2()
    throws java.io.IOException
  {
    assertEquals(_resin.request("GET /test.php?a=1&b=2"), "1 + 2 = 3");
  }

  @AfterClass
  public static void shutdown()
  {
    if (_resin != null)
      _resin.destroy();
  }
}

[edit] Administration tools

[edit] Nagios

Resin features a customizable REST-style interface for its administration application which can expose statistics and JMX data to external tools such as Nagios. For Nagios specifically, Caucho's community wiki features downloadable scripts to make this integration easier. The REST interface and Resin administration application are written in PHP and run within Resin using Quercus, Caucho's reimplementation of PHP written in Java. This architecture makes writing administrative scripts fast and easy. For example, the following script shows how to expose thread pool information to Nagios:

<?php

include_once "nagios.php";

$jvm_thread = $g_mbean_server->lookup("java.lang:type=Threading");
$thread_pool = $g_server->ThreadPool;

$msg = "pool active: {$thread_pool->ThreadActiveCount}, " .
       "pool idle: {$thread_pool->ThreadIdleCount}, " .
       "pool count: {$thread_pool->ThreadCount}, " .
       "jvm count: {$jvm_thread->ThreadCount}, " . 
       "jvm peak: {$jvm_thread->PeakThreadCount}";

nagios_output($thread_pool->ThreadActiveCount, $msg);

?>

The output from this script is gathered by a matching Nagios shell script and stored in the Nagios database. The administrator can configure custom ranges for the data gathered to indicate an OK, WARNING, or CRITICAL state. The PHP and shell scripts for these functions are provided on the Caucho Nagios wiki page.

[edit] Appendix: Translation glossary