Migrating from WebLogic to Resin

Migrating to Resin from WebLogic

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.

Managing configuration

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.

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

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.

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. This architecture affects how Resin is started and stopped, especially compared to WebLogic. WebLogic users typically create startup scripts for their server to manage aspects of startup such as the classpath, JVM arguments, and override configuration. Resin's Watchdog uses the same configuration files as the actual Resin server and it is in charge of launching the JVM for Resin, so instead of creating scripts, Resin users simply have all of their startup configuration located in a single file. Overriding values in the Resin configuration is typically not necessary because the files are readily editable, but facilities such as using expression language for system properties allows the user to set options on the command line for this purpose. 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.

Application Deployment

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.

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.

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

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.

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

To use another the context root, use

 mvn resin:upload-war -Dresin.contextRoot="bar"

To upload a version without making it live:

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

To make that version live using the copy-tags goal:

 mvn resin:copy-tag -Dresin.sourceContextRoot='foo' -Dresin.sourceVersion='1.0'

To query all versions of the webapp in the repository:

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

Appendix: Translation glossary

Term	Resin	WebLogic
Root directory	Directory holding all site content. Typically /var/www or C:\www. Webapp files and virtual host directories are located here. Logs are also commonly located here (/var/www/log), though other locations are also possible.	AKA Server root. Stores runtime data associated with each server. [4]
Staged deployment	A deployment mode in which applications are copied to all servers in a cluster, but only available from servers in the appropriate stage. E.g. servers in "default" stage mode serve all applications in the "default" stage, servers in the "preview" stage mode only serve "preview" stage applications, etc.	A deployment mode in which applications are copied to all servers, but not activated until all servers have a copy of the applications.