In this post I’d like to provide a complete listing of all commands available in Resin. First, let’s enable resin:ManagerService. Open your resin.xml file and add <resin:ManagerService/> into <cluster-default> section. If you running Resin-Pro look for <resin:AdminServices/> tag and uncomment it. Remember that <cluster-default> applies settings to all configured clusters, e.g. app-tier and web-tier. (more…)

After a long few months of hard-work, we finally see the light at the end of the tunnel for getting Resin 4 Java EE 6 Web Profile certified!

We are now passing the Servlet 3.0, JSP 2.2,  EL 1.2, JSTL 1.2, JSF 2.0, Bean Validation 1.0, CDI 1.0, JPA 2.0, JPA 2.0 and JMS 1.1 TCKs. Note, although JMS is not part of the Java EE 6 Web Profile, we are still implementing it since a number of our customers have asked for a lightweight messaging option in Resin.

The last TCK that we need to pass at this point in order to be Java EE 6 Web Profile compliant is EJB 3.1 Lite. As such, we do have the basic functionality for stateless session beans, stateful session beans and singleton beans including life-cycle, concurrency, registry/look-up, interceptors, security and transactions. Indeed, Adam Bien recently blogged about the usability of the current Resin 4 development release: http://www.adam-bien.com/roller/abien/entry/java_ee_6_server_resin and we have been demoing full-stack Java EE 6 applications for a while now including at JavaOne 2010 (albeit without EJBs, using EJB service annotations/aspects directly in CDI managed beans).

Resin TCK Progress

At this point, it is a matter of working through the cases caught by the EJB 3.1 Lite TCK. I’d say a majority of it is minor bug-fixes with singletons having the most and stateless session beans the least amount of issues.

Although technically not part of EJB 3.1 Lite, we are also implementing scheduling, asynchronous processing, remoting (Hessian based) and message driven beans because we feel these are valuable parts of the EJB specification. We will also include a JCA implementation for better resource pluggability. At this point, we have the basic functionality of timers/scheduling as well as asynchronous processing done. The remoting and the message-driven bean/JCA parts still need significant work, including creating a new messaging model around CDI events as a supplement to the older message driven bean model. My personal guess is that we will have the officially Java EE 6 Web Profile certified release of Resin 4 by the end of the year. We will then have a few releases focused purely on stability, optimization, foot-print, start-up/shut-down time and runtime performance since these have always been primary differentiators for Resin.

The final release of Resin 4 will allow us to then focus on some of the work around CDI portable extensions that we wish to do including Seam 3 modules/Arquillian integration as well as things like HTML5/WebSocket, modularity, cloud/NoSQL APIs, etc.

Obviously, Resin 4 is a very important milestone for us as a team but is very significant for the Java EE 6 ecosystem too. I would expect the JBoss guys to announce their final Java EE 6 compatible version shortly after us, probably followed by Geronimo, WebLogic, etc.  It seems IBM has been uncharacteristically proactive with the WebSphere Java EE 6 work too.

In the meanwhile, do send us your comments and wish us luck on the final stretch of the Java EE 6 implementation marathon!

Speaking at TSSJS Vegas this year was great. I got to do four talks - a Java EE 6 overview, a Resin demo, a CanDI/CDI demo as well as a talk on the JCP. The Resin talk was one of the keynotes for TSSJS. All talks were well attended and the crowd was great. People seemed genuinely interested in Java EE 6, the Web Profile, CDI and Resin. I got a ton of questions for Q & A, one-on-one afterwards as well as at the booth. Folks were particularly interested in some of the CDI/EJB 3.1 features as well as our portable extensions for JUnit, iBATIS, Quartz, using EJB annotations on managed beans, etc. A good number of people asked for the example code both for the CanDI and Resin talks. I personally enjoyed taking about open participation in the JCP although it was a relatively short and non-technical talk. We will be posting the slides as well as the code examples on the website soon. I hope we get similar success in JavaOne as well as other conferences.

We at Caucho are very excited in working steadily towards getting Resin certified on the recently finalized Java EE 6 Web Profile. Along with GlassFish and JBoss, we are aiming to provide one of the earliest solid implementations for Java EE 6. In fact, Resin is the only major application server focused solely on delivering a very lightweight implementation targeting just the Web Profile.

This blog entry briefly discusses the Java EE 6 Web Profile, what it offers and how it fits with the lightweight development philosophy of Resin as well as the details of our implementation including Resin extensions to the Java EE 6 Web Profile.

(more…)

Like other lightweight servlet containers and Java EE application servers, Resin’s deployment is file-system based. In order to deploy an application, all you need to do is copy your file to the Resin deployment directory. As you might also know, Resin has supported hot deployment for quite a while, which is a great feature for agile development that often results in frequent incremental deployments.

This deployment model is very simple, effective and popular. However, file-system based deployment has a few weaknesses that can arise in environments with very stringent availability and reliability requirements. It is very difficult to do deployment in a clustered environment because the same file must be deployed simultaneously to all servers in the cluster. Often this can result in some down-time that must be announced beforehand. No back-up facility is provided by the file system, so you must often save a backup copy of the old deployment somewhere yourself. File system based deployment also makes it very difficult to use the same server environment for different stages of development such as QA, user acceptance testing and production without following complicated deployment procedures.

The remote deployment model introduced in Resin 4.0 goes a long way in solving these particular problems by supporting clustered, versioned and staged deployment. This blog entry discusses these features in detail.
(more…)

We’ve been quiet on the blog for a while, but pretty busy behind the scenes for the last couple of weeks. There’s lots going on, but what I’m working on specifically is a new deployment model for Resin 4. In addition to our current file system based hot-deploy, we’re now adding a deploy model based on Git. We introduced this in Resin 4.0.0 and 4.0.1, but we started exploring the benefits of Git repositories and realized that we have the ability to do some really powerful things like sophisticated application versioning and rolling out applications in stages. I’ll show you the new model and give a preview of how you can use it in upcoming versions of Resin.

(more…)

Over the last few months, I’ve been talking to a lot of people, doing conference sessions about cloud computing and I’ve found out a lot about the different architectures in this space. I’m still very happy with our architecture (perhaps even happier) even after of all these discussions. In past blog posts and in our whitepaper, we’ve explained how the new Resin 4 cloud architecture works. Now I’ll talk a little about why it’s a nice alternative to other approaches.

(more…)

We use WordPress for this blog and I recently upgraded to the 2.7.1 version. The developers have started using a .htaccess file with Apache mod_rewrite rules, so we need to emulate that to support certain things like permalinks. This is a quick and trivial example, but it gives a glimpse at our new rewrite dispatch syntax in Resin 4.

(more…)

Because Resin 4.0 can now use Java Injection (JSR-299) for its configuration, we’ve taken advantage of the new syntax to redesign Resin’s rewrite and dispatch capabilities, used for sites migrating from Apache’s mod_rewrite module. The admin documentation is at http://caucho.com/resin/admin/rewrite.xtp and the JavaDoc for the tags is at com.caucho.rewrite (the JavaDoc describes the tags because Resin-rewrite uses Java Injection - JSR-299 for configuration.)

Rewrite matches HTTP URLs with a regular expression and dispatches them to servlets or load-balancing or HTTP proxies or HTTP redirects. PHP applications like MediaWiki and Drupal use rewriting to present pretty URLs to the world, but use /index.php internally.

(more…)

There’s a lot of talk about “Cloud Computing” right now, including from Caucho, but much of it seems vague or over-hyped. You hear more talk about benefits of scaling, redundancy, and cost savings than about actual features. We recently put out a whitepaper talking about Resin 4.0’s support for cloud that hopefully shows what we’re providing. However it is a pretty big document with quite a bit of behind the scenes technical detail, so I thought I’d break it down a bit here to give you a look at where we fit into the cloud environment. In other words, here are the actual features in Resin 4’s cloud support.

(more…)