Migrating from WebLogic to Resin
From Resin 3.0
Contents |
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.) 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.
