With Resin 4.0, we can expose our distributed caching/store capabilities to all developers, using the javax.cache interface. Internally, our distributed cache builds on 10 years of work with distributed sessions. So the jcache support isn’t a new capability, really, it’s just newly available for developers.

As an introduction, I want to show the prototypical code sample (it’s an injected Map), and the configuration (one XML tag in the resin-web.xml). The configuration is simple because Resin’s clustered cache is designed for Resin and automatically inherits the cluster and triad configuration from the Resin deployment.

Distributed caching reduces load on the database, improves latency, and can improve reliability by providing a failover capability in a load-balancing configuration. Essentially, you store serialized objects in a Map and the cache makes the Map entries visible across the entire cluster pod automatically.

(more…)

With Resin 4.0’s WebBeans support, we can finally modularize and cleanup features like security, JMS, clustering and remoting. Since the WebBeans-style XML configuration selects a component based on package and classname, our XML configuration for security exactly matches our classes. For example, <sec:IfNetwork> is com.caucho.security.IfNetwork. Our JavaDoc can even serve as XML documentation and as Emil’s post shows, we can enable Eclipse to display those tags automatically.

JavaDoc is available for com.caucho.security, as well as documentation for Resin 4.0 security.

Since examples make configuration clearer, I’ve put together three typical security configurations:

• IP address protection: restricting admin pages to the local network
• Hiding pages from all browsers, like WEB-INF
• HTTP basic authentication for quick and dirty password protection

(more…)