Resin's configuration is now organized into "Environments". Each environment has its own classloader, JNDI space, resources, logs, system properties, etc. The Environment is just a generalization of Resin 2.1's class-loader context for <http-server>, <host>, and <web-app>. Now, any context could have its own environment: EJB servers, the outer <resin> declaration, even individual session beans.

Any of the class loader and resource configuration is allowed in any environment. See the environment configuration for the list.

Class loading configuration has been split from the old classpath into a new set of class loading implementations: compiling-loader, simple-loader, library-loader, and make-loader. These are primarily intended to make class loader configuration more clear.

reference configures JNDI ObjectFactories, while resource configures bean objects directly. Several third-party components expect to be configured as ObjectFactory references instead of configured as beans.

With the exception of replacing <reference-ref> with the new <database>, database configuration is similar to the old style. <driver-class> and <driver-url> are the new primary subtags of the <database> configuration.

For transactions, <xa>true</xa> configures the DataSource as transactional.

<ejb-server> now replaces the resource configuration for com.caucho.ejb.EJBServer.

Resin's support for web-app defaults and host defaults is now more consistent and robust. All the defaults, including *.jsp and the configuration of WEB-INF/classes and WEB-INF/lib, are now implemented using web-app-default and host-default. The distribution puts these in $RESIN-HOME/conf/app-default.xml.

All the configuration items in web-app-default are applied to the web-app at initialization time. Since web-app-default items are applied first, the later web.xml definitions will override them.

.war deployment has been generalized from the simple war-dir in Resin 2.1. "webapps" directories can now be subdirectories of a web-app. For example, doc/servlet/tutorial is an expansion directory. All the tutorial examples are separate web-apps added automatically.

The configuration of directories for server, host, and web-app has been cleaned up to remove some confusion.

The <server> has only a root-directory. The server's root-directory specifies the top-level location for log files, caching, etc.

The <host> has a root-directory and a document-directory. The root-directory defaults to the server's root-directory if none is specified. The document-directory is the location for the host's documents.

The <web-app> has only a document-directory. It replaces the app-dir configuration.

All configuration in Resin is now based on bean-style configuration using XML to configure beans. Each tag in all the configuration files corresponds to a setXXX or addXXX or createXXX method in a bean.

The configuration allows JSP-EL expressions in any context where primitive values are allowed. So any string or path can be configured with JSP-EL using variables like ${serverId}.

Servlets and Filters can be configured with <init> blocks that use the full power of Resin's configuration. So the following configuration would be possible:

Resin's logging is now integrated with the JDK 1.4 java.util.logging classes. The log configuration configures the Logger classes. So applications which use JDK 1.4 will automatically get integration with Resin's log configuration.

Resin's threading and TCP accept implementation has been rewritten. All ports for a <server> now share the same pool of worker threads.

For the most part, this change should be invisible to most users.

On Unix, Resin has JNI support for "nonblocking" I/O for keepalive connections. (Resin 3.0 uses select instead of a true nonblocking call.) This new support means Resin can support many more keepalive connections without dedicating any threads.

In other words, an application could have 500 keepalive connections waiting for a client response and only need 5-10 active threads to process that response.

This support is not yet available for Windows. Under Unix, you must ./configure, make, and make install the libexec/libresin.so to get the new keepalive support.

Most of the capabilities of bin/resin are now handled by JNI. The <user-name> and <group-name> support have not yet been added to Resin 3.0.x. Older versions of Linux will need to use an alternative method of changing the user. Newer Linux versions will be able to use the JNI-based <user-name> once that's reintroduced.

Since the JavaScript for JSP was used by too few users, it no longer makes sense to continue support.

In addition, the JSP-EL and JSTL tag libraries make the need for a separate dynamically-typed language less important.

The plugins, mod_caucho and isapi_srun.dll, have been changed significantly. The plugin configurations are truly "beta" quality as more work is needed to bring them up to the usual Resin standards.

If you intend to deploy with Resin 3.0.0-beta, it is highly recommended that you use Resin standalone instead of using Apache or IIS. The quality issues are expected to be resolved by 3.0.1.

The plugins now use the HMUX protocol to talk from Apache/IIS to the Resin backend.

The plugins also now query the backend for their configuration. They no longer read the resin.conf independendly. (This is the part that's very new.)

Resin's load balancing and session backup has been cleaned up and generalized somewhat. <srun> ports now belong in a <cluster> definition. This should make the configuration a bit clearer.

The appropriate load balance servlet is now com.caucho.servlets.LoadBalanceServlet. It uses the HMUX protocol as the plugins do.

The Caucho servlets are now in com.caucho.servlets. The filters are in com.caucho.filters.

The authentication classes are in com.caucho.server.security.

We do plan to implement backward compatibility classes for those who have used custom authenticators, but this has not yet been done.

The next versions of the JSP and Servlet specs are currently in the draft stage. Resin 3.0 does implement the new specs, but may not yet be fully up to date on the latest drafts.