Any bug you find in 3.0.4 should be reported in the bugtrack.

Because of the large number of changes from Resin 2.1 to Resin 3.0, developers should stress test their application with Resin 3.0.4 thoroughly before deploying it.

The thread pooling and connection management has changed dramatically for Resin 3.0.4. With the exception of the new <thread-pool> configuration, this should be invisible for most users except as a gain in scalability.

Performance for static files is now essentially the same as Apache 2.

The new thread model now better supports large number of simultaneous connections, e.g. 300 and 500 simultaneous open sockets.

The single thread pool is shared across all of Resin, so the configuration is in <resin> and outside of <server>.

The old <connection-pool> has been deprecated and will be removed in Resin 3.0.5.

Amber is Resin's new persistence manager, currently in development. We have added some sample tutorials as a preview. Since the tutorials are direct translations of the old CMP tutorials, you can compare the two persistence methods directly.

We are very excited about the Amber direction and believe it will avoid the complexity of J2EE/EJB for 80% of projects, reducing development time and engineering cost.

Amber will likely eventually provide facades for Hibernate and JDO 2.0 when that is available. During development, we'll only be supporting Amber's native API.

Amber currently uses Hibernate's configuration files and its API model resembles Hibernate, but uses JDBC more directly. Amber's lifecycle is patterned after JDO, using bytecode enhancement to make the JDO state changes possible.

Amber's JDBC use appears in its queries. Here's an example:

Persistent session support for JDBC has been enhanced to take advantage of clustering and sticky sessions. Each session now has a preferred owning server which reduces the overhead of the session persistence, and removes the need for always-load-session.

Because of these enhancements, we now recomment jdbc-store over tcp-store for most configurations.

The changes affect the configuration files. Because the jdbc store is now cluster-aware, it needs to be configured in the <cluster> and merely enabled in the <session-config>. A typical configuration will look like the following:

Virtual hosts can now be deployed like .war files. Virtual hosts do need to a .jar extension. The <host-deploy> configures the virtual host deployment.

Because there is no standard for virtual host deployment, Resin allows the flexibility to configure the layout as the site needs. We recommend using a pattern following Resin's virtual hosts, the host root-directory contains doc/, webapps/ and log/.

Because both Servlet 2.4 and JSP 2.0 are still in draft stage, Resin's support is considered beta. However, we don't expect the specs are likely to change much from the current draft to the final draft.