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…)

It’s the last day of TSSJS here in Las Vegas and it’s been a really successful and fun conference so far. The skill level of the attendees is great, meaning a lot of meaningful conversations on the industry and trends in development. On Wednesday, our CEO Steve Montal gave a quick 5 minute overview of our current and upcoming technologies like Resin 4 with Java CanDI and cloud support as well as Quercus. There was a lot to pack in, but even this short speech garnered us a lot of attention. We also handed out our Resin 4 whitepaper which I think was well-received.

Thursday was a particularly interesting day because of talks at the beginning and end. Rod Johnson started out with a talk on Spring, where he (once again) declared JavaEE unnecessary and overly complicated. He claimed that an acquisition of Sun by IBM would be meaningless to developers, because nobody cares what they do anyway. It was a bit controversial to say the least. The part that irked me the most was that he claimed that SpringSource is the only independent application server vendor left… Caucho has been around for 10 years and is going strong, even in this economy. We predate Tomcat and SpringSource, so I think Rod was mistaken on this point.

At the end of the day, Reza Rahman lead a discussion of the direction and progress of JavaEE 6. We’re targeting the Web Profile and we’re participating in the JSR-299 (Java CanDI) expert group, so naturally we were interested in the community’s opinion of the new standard. There was an interesting debate on the contents of the Web Profile, with a lot people arguing for a profile that does not include a view technology. Reza explained that the view of the committee was that a JavaEE certified project needs to be able to build a complete application out of the box without add-ons, yet not prevent add-ons. The Web Profile is targeted at the 80% of developers who don’t need the extra bells and whistles of the full profile.

It turns out that the only thing holding up JavaEE 6 is the debate over Java CanDI and whether it should be included. There are not a lot of complaints about the technology itself, but rather its scope. What I found interesting is that while this topic seemed to be very contentious within the JEE 6 EG, the attendees of this session just wanted Java CanDI in. Its utility was apparent to them and they didn’t care about the political debate, they just want it in. Of course, that’s just what I heard…

Update: If you want the Java EE 6 spec committee to include Java CanDI (aka JCDI, aka JSR-299), let them know at jsr-316-comments@jcp.org

Over the last couple of weeks, I’ve been preparing a whitepaper to explain the technical backing of Resin 4.0’s dynamic clustering support. We’re planning to have it available in printed form at this month’s TSSJS in Las Vegas, but you can download it now!