resin

Resin 3.0.1 is the second beta release of Resin 3.0.x.

Because of the large number of changes, developers should stress test their application with Resin 3.0.1 thoroughly before deploying it.

We are calling the Resin 3.0.x series "beta". The "production" versions will be the Resin 3.1.x series. The two reasons for calling the code "beta" is the large number of changes, and because we are expecting to add a great deal of features to following 3.0.x releases. For many users, the stability of 3.0.x will be sufficient for deployment, but we wanted to give an extra warning to make sure that people stress tested their applications before deploying on 3.0.x.

Resin 3.0.1 implements the complete JSP 2.0 third draft. Any discrepancies should be reported as bugs.

In particular, Resin 3.0.1 adds support for *.tag and *.tagx files, see .tag tutorial.

Resin 3.0.1 does not yet include the full support for the third draft of Servlet 2.4. In particular, the ERROR dispatch configuration for filters and the Request listeners have not yet been implemented.

Resin 3.0.1 includes a large number of persistent session changes. Large parts of that section of Resin has been reimplemented.

Configuration-wise, the changes should be minimal. The <persistent-store> is configured outside the <session-config>, or for TCP (cluster) sessions, the <cluster-store> is configured inside the <cluster> definition itself. Old-style resin.conf and web.xml are still accepted.

Resin 3.0.1 now allows for many more sessions on disk than in memory. session-max continues to specify the maximum number of sessions allows in memory, but the number of session stored on disk may be much larger.

This change will allow sites to set very large session-timeout values, e.g. 24 hours or even 1 month, and allow the sessions to be saved in the persistent store without overloading the memory.

jdbc-store now understands the owning server for a session, as tcp-store always has. Now, when a request goes to the owning server for the session, the jdbc-store does not need to query the database for any updates (backup servers will always need to query the database.

By saving that query, jdbc-store should now be about as efficient for a load-balanced configuration as tcp-store, as long as the load balancer understands sticky sessions. (If the load balancer always sends requests to random servers, there is a smaller probability that the request will reach the owning server.)

always-save-session now checks the CRC-64 hash of the serialized session to see if any changes have occurred. If the hash is identical, Resin will know not to save the serialized value, saving either a database trip for jdbc-store or a TCP update for cluster-store. The session will still incur the cost of serialization.

<resource> now recognizes ResourceAdapter and ManagedConnectionFactory resources. If the configured resource implements ResourceAdapter or ManagedConnectionFactory, Resin will call them with the appropriate lifecycle methods.

The Resource tutorials show how resources can take advantage of these callbacks.

The new CronResource now replaces the old run-at servlets. The CronResource accepts an application WorkTask which it executes at specific times, configured following the Unix cron syntax.

<resource type="com.caucho.resources.CronResource"> <init> <cron>10 3,18</cron> <work bean-class="example.WorkTask"> <value>Example</value> <jndi>java:comp/env/example</jndi> </work> </init> </resource>

Resin 3.0 now has a limited direct support for EJB/XDoclet generation. The internal XDoclet generator is run as part of <make-loader>, the make classloader. Most of the CMP examples have been expanded to use XDoclet.

<web-app xmlns="http://caucho.com/ns/resin"> <class-loader> <make-loader path="WEB-INF/classes"> <ejb-doclet srcdir="WEB-INF/classes"/> </make-loader> <compiling-loader path="WEB-INF/classes"/> </class-loader> </web-app>

The clustering configuration (srun) has changed slightly. The <srun> elements must now be in a <cluster> block.

<resin xmlns="http://caucho.com/ns/resin"> <server> <cluster> <port id='' host='127.0.0.1' port='6802'/> </cluster> ... </server> </resin> r_cluster = element cluster { attribute id { string }? & (r_cluster-port* | r_cluster-group*) & r_cluster-store?) } r_cluster-group = element group { r_cluster-port* } r_cluster-port = element port { r_cluster-port-Contents }

Persistent store is now configured separately from the <session-config>. This will allow the persistent store to manage distributed objects for things other than sessions and is also needed for the lazy-init to work with cluster store.

<resin xmlns="http://caucho.com/ns/resin"> <server> <cluster> <port server-id="a" port='6810' index='1'/> <port server-id="b" port='6811' index='2'/> <cluster-store name="caucho/store" path="session"/> </cluster> <host id=''> <web-app id='/'> <session-config persistent-store="caucho/store"/> </web-app> </host> </server> </resin> <web-app xmlns="http://caucho.com/ns/resin"> <persistent-store name="caucho/store" type="jdbc"> <init> <data-source>jdbc/session</data-source> </init> </persistent-store> <session-config persistent-store="caucho/store"/> </web-app> r_persistent-store = element persistent-store { r_name, (attribute type { string } | element type { string }), init? } r_cluster-store = element cluster-store { (attribute name { string } | element name { string })?, (attribute path { string } | element path { string }), (attribute always-load { string } | element always-load { string })?, (attribute always-save { string } | element always-save { string })? }

Resin 3.0.1 adds experimental support for custom dependency checking. With <dependency>, a web.xml can specify that the Application should be restarted when a specified file changes, just like the web.xml. For example, a user could specify the struts-config.xml.

<web-app xmlns="http://caucho.com/ns/resin"> <dependency path="WEB-INF/struts-config.xml"/> ... </web-app> r_dependency = element dependency { (attribute path { string } | element path { string }) }

Resin 3.0.1 adds preliminary support for EAR files with the <ear-deploy> configuration element. The deployment directory, specified by the path, is the location for the .ear file. That directly may safely coexist with the webapps directory, since the expanded directory names are unique.

<ear-deploy> may occur in the <host> and the <web-app> context.

r_ear-deploy = element ear-deploy { (attribute url-prefix { string } | element url-prefix { string })? & (attribute path { r_path } | element path { r_path }) & (attribute expand-path { r_path } | element expand-path { r_path })? & r_lazy-init? }

Resin 3.0.1 adds preliminary support for RAR files with the <resource-deploy> configuration element. The deployment directory, specified by the path, is the location for the .rar file. That directly may safely coexist with the webapps directory, since the expanded directory names are unique.

<resource-deploy> may occur in any environment context, e.g. <server>, <host>, or <web-app>.

The resources found by the <resource-deploy> are configured and created with the <connector> element.

r_resource-deploy = element resource-deploy { (attribute path { string } | element path { string }) & (attribute expand-path { string } | element expand-path { string })? }

The new connector element is used to configure .rar resources. Old style connectors will have a single <connection-factory> interface. New-style connectors (Connector 1.5) can include a separate <resource-adapter> configuration.

<web-app xmlns="http://caucho.com/ns/resin"> <resource-deploy path="WEB-INF/deploy"/> <connector type="example.TestResourceFactory"> <connection-factory name="jca/t1"> <init><value>a</value></init> </connection-factory> </connector> </web-app> r_connector = element connector { r_type & r_resource-adapter? & r_connection-factory* } r_connection-factory = element connection-factory { r_name, r_type?, r_init? } r_resource-adapter = element resource-adapter { r_name?, r_init? }

libresin.so will not yet compile for MacOS-X. Resin will still run without it, but OpenSSL is not available and the JNI enhancements are not available either.
The IIS and Apache plugins are still definitely of experimental quality.