I just came back from a trip to the Raleigh, NC area to record a JavaLobby Tech Chat on Resin 4 (last year Emil did a Tech Chat that you might have seen). The Tech Chat went great. Mitch Pronschinske, the Editor-in-Chief of JavaLobby/DZone drove the Chat. Not to give away too much right now but we talked about:

• Past/present/future of Resin
• Defining characteristics of Resin - lightweight, standard and feature-complete
• Resin 4 Java EE 6 Web Profile certification
• Java EE Web Profile leadership
• How it stacks up against Tomcat/JBoss/GlassFish/WebLogic/WebSphere
• Small, dedicated, agile World class engineering team
• CDISource - a vendor-neutral space for all things CDI
• The CDISource Spring/CDI bridge
• Possibilities for Java EE 7/Java EE 8 (open for participation from you!)
• Early Resin WebSocket support
• Resin support for private clouds

Keep your eye on JavaLobby - the Tech Chat should be out there soon!

I chose to drive to NC to avoid the hassle of flying and because NC is quite drivable from my home office in Philly. On the way back, I did CDI demos at both the Research Triangle JUG and the NoVA/Washington, D.C. JUG. Both talks were very well attended. The interest/participation levels were fantastic. The DZone folks gave me a few nice printed copies of the CDI RefCard. Every single copy was taken and people were asking for more! They also asked me for the slide deck and code examples. I’ll send them to the JUG leads to post on the JUG websites. You can also take a look at the slide deck and code examples if you want and send me any follow-up questions. I also wanted to talk at the Maryland and Richmond JUGs but things didn’t quite work out schedule-wise this time around. Both JUGs are working on scheduling me to speak in the Fall instead.

TSSJS 2011 went extremely well for us. Our talks/events went very well and the booth attendance was great. I think the TSSJS 2011 agenda, quality of content/speakers and buzz was the best in years. The new TSS editor Cameron McKenzie did an admirable job at putting everything together.  Some of the notable speakers included James Gosling, Steve Harris (SVP Oracle), Adam Messinger (VP Oracle), Patrick Curran (JCP chair), Rod Johnson, Bill Burke, Adam Bien and Kirk Pepperdine.

I started the conference with a 5-minute lightning round presentation on Resin 4, the Java EE 6 Web Profile, our vision, history, thought leadership, values, global footprint and growing customer base. The presentation seemed to go over well with a number of existing customers and developers reaching out to us afterwards.

The first session on the first day of the conference I did was my enterprise caching talk titled “Effective Caching Across Enterprise Application Tiers”. The talk covers the different flavors of caching in the web (HTTP), presentation, application, domain, infrastructure (persistence) and resource (database) tiers using mechanisms like proxy caching (especially as supported by Resin), JSF/CDI @ApplicationScoped, @SessionScoped, @ConversationScoped, @ViewScoped, @RequestScoped scopes, passivation, EJB pooling, EJB thread-safe singletons, extended persistence contexts, JPA first (transactional) and second (shared) level caching, database connection pools, prepared statement caching, JCache as well as distributed caching APIs like Coherence, Terracotta, GigaSpaces, Infinispan, EHCache, JCS, SwarmCache and OSCache. The talk was very well attended, the Q&A was good and I got great feedback afterwards. In the evening, I participated in the “Meet the Authors” event. TSSJS gave away two copies of EJB 3 in Action (I am currently working on the second edition) and I signed both copies for the winners. I had a few engaging conversations on topics like EJB/Spring, authoring and the JCP during the course of the evening.

I started the second and busiest day of the conference with a panel titled “The Java Community Process: What’s Broken and How to Fix It”. This was a panel with Patrick Curran, James Gosling and me, moderated by Cameron McKenzie. We discussed the need for reforming the JCP, greater transparency, the Apache Harmony licensing issues, more non-Oracle spec leadership and more participation from non-vendor affiliated independents. We all agreed that many ills in the JCP can be cured through greater interest and participation from the developer community. The panel generated a great deal of interest, attendance, participation and feedback. After lunch, I gave my “A Quick Tour of the CDI Landscape” talk. The talk is a broad overview of the vibrant CDI landscape composed of implementations, supported runtimes, portable extensions and tools. I discussed Weld, CanDI, OpenWebBeans, GlassFish, JBoss AS, Resin, Geronimo, WebLogic, WebSphere, Tomcat, OpenEJB, TomEE, JOnAS, Seam 3, Apache MyFaces CODI, the ZK Framework, Arquillian, Forge, JBoss Tools, Eclipse, NetBeans and IntelliJ. The audience was great and I had some lively discussions afterwards. Later in the afternoon, I did my Java EE testing talk titled “Testing Java EE 6 Applications: Tools and Techniques”. The talk covers end-to-end testing along the entire Java EE stack including Servlet 3, JSF 2, EJB 3.1, JPA 2, JAX-WS and JAX-RS using existing and emerging tools like JUnit, HttpUnit, HtmlUnit, Cactus, Selenium, JSFUnit, embedded containers, embedded databases, Arquillian/ShrinkWrap, Resin JUnit integration support and soapUI. The talk was well attended and I got excellent feedback for the talk. It was only somewhat surprising that folks don’t realize how robust Java EE testing is with the latest release and tools like Arquillian. In the evening, I participated in the “Ask the Experts” session which also went very well.

The last day of the conference I presented my talk titled “An Introduction to Seam 3″.The talk discusses the relationship between CDI, Weld and Seam 3 as well as covering all the Seam 3 modules such as XML configuration, persistence, Faces, Servlet, JMS, REST, JavaScript remoting, security, internationalization/localization, exception handling, mail, cron, document generation, Spring interoperability, Wicket, GWT, Drools, jBPM, JBoss ESB and so on. Since it was towards the end of the conference the attendance was relatively sparse but the Q&A session was very good with a lively audience.

A number of folks asked for the slides and demo code, so the materials for the talks is posted here.

A good number of folks stopped by at the Caucho booth to talk to us. We had an excellent location this year for the booth and people saw us last (almost). I think we had the best booth traffic of any conference so far. The guitar giveaway seemed to go over very well too. We can only hope that next year is just as successful!

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

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!

Overall, Caucho had a great JavaOne this year. Our talks went very well, the booth attendance was great and a number of people showed up at the meet-and-greet.

The first session we did was the Resin 4 Java EE 6 Web Profile talk titled “Resin: A Light-footed Java EE 6 Web Profile Platform”. This was the first time Emil and I co-presented and I thought it went very well. The attendance was moderate but we had a number of good questions and a handful of folks asked for the slides/demo code afterwards. That same evening I did a CDI BOF with Dan Allen of Red Hat/JBoss and David Blevins of Apache OpenWebBeans/OpenEJB. The BOF was titled “Implementing CDI: Goals, Milestones, and Perspectives” and was well-attended. We had lively discussion around the current state of implementations, the CDI ecosystem as well as the future of CDI/Java EE. A lot of folks gave us positive feedback on the BOF, particularly on our plans going forward for Java EE.

My first talk for the second day of the conference was the Java EE testing talk with my EJB 3 in Action co-author Debu Panda titled “Testing Java EE 6 Applications: Tools and Techniques”. It was a full house and the talk went very well although we ran out of time and could not demo JAX-WS/JAX-RS testing. The talk covered end-to-end testing along the entire Java EE stack including Servlet 3, JSF 2, EJB 3.1, JPA 2, JAX-WS and JAX-RS using existing and emerging tools like JUnit, HttpUnit, HtmlUnit, Cactus, Selenium, JSFUnit, embedded containers, embedded databases, Arquillian/ShrinkWrap, Resin JUnit integration support and soapUI. We got excellent feedback for the talk. It was only somewhat surprising that folks don’t realize how robust Java EE testing is with the latest release and tools like Arquillian. Debu was in great form for the talk as usual. In the evening I did an EJB 3.1 BOF with Linda Demichael of Sun/Oracle, Mike Keith of Sun/Oracle, David Blevins of Apache OpenWebBeans/OpenEJB as well as Andy Rubinger of JBoss/Red Hat titled “Enterprise JavaBean (EJB) Community Discussion”. The attendance was moderate but the discussion was very lively. It was very encouraging that we were more-or-less on the same page about the future direction of the EJB spec.

The last session I did for the conference was on Wednesday. It was a panel with Adam Bien, Emmanuel Bernard of JBoss/Red Hat, Krasimir Semerdzhiev of SAP, Roberto Chinnici of Sun/Oracle, David Blevins of OpenWebBeans/OpenEJB and Jim Knutson of IBM titled “Java EE 6 Panel: What Do We Do Now?”. The panel was moderated by Alexis Moussine-Pouchkine of Sun/Oracle. He blogged about the panel here. It was a full-house and we had very lively discussion. I talked with several of the panelists afterwards and it was very encouraging that folks are actively thinking about what really should be done in Java EE 7 and mirrored what we are doing in Resin/CanDI.

The material for our talks is posted here.

A good number of folks stopped by at the Caucho booth to talk to us. We had an excellent location this year for the booth and people either saw us first or last. We can only hope we are that lucky next year! The meet-and-greet was good too and met up with a handful of friends including Andrew Schaefer and Ryan de Laplante. I also of course met up with the usual suspects from JBoss, SpringSource, Apache, Sun/Oracle, etc throughout the conference.

I have mixed feelings about the conference itself. The programming and organization was great but I could not help but feel that JavaOne was demoted. I think a lot of developers have this same sentiment and I hope Sun/Oracle will do better next time.

For people who want to use CDI, the most difficult problem is a large legacy of existing code. Rewriting an entire codebase is not possible (and not wise) and evolutionary change has proven itself as more effective and manageable, even if it doesn’t sounds as impressive as a full rewrite. So the trick to migrating to CDI is finding ways to change one piece of the project.

If you have a service-oriented architecture (when used a legitimate design pattern, not the web services buzzword), you can explore CDI with one service, and transition between the styles using JNDI to enter the CDI environment. A module inside a framework also fits this pattern, like an application within wicket. Essentially, any case where the framework is non-CDI but you want to write a module using CDI. The key is getting access to CDI’s programmatic interface BeanManager using JNDI.

The code to load a CDI-enabled service inside a framework with JNDI is boilerplate. You’ll want to put it in a utility class. The class you load with the utility will be your main service entry, or a root node in a component graph. You’ll use the code like the following, where “myBean” is a fully CDI-enabled bean with injection, interception, XA annotations, events, etc:

The utility class is boilerplate code. The BeanManager code is an SPI interface and it’s a bit more verbose than API code, but the added flexibility for framework integration is worth the added complexity. This integration code is only needed at the boundary of CDI and inside a foreign web framework; it’s not needed within a CDI module.

import javax.naming.*;
import javax.enterprise.context.spi.*;
import javax.enterprise.inject.spi.*;
import java.util.*;

public class CandiUtil {
  private BeanManager _cdiManager;

  public <T> T getReference(Class<T> beanClass)
  {
     BeanManager cdiManager = getBeanManager();

     Bean<T> bean = (Bean<T>) cdiManager.resolve(cdi.getBeans(beanClass));
     CreationalContext<T> env = cdiManager.createCreationalContext(bean);

     return cdiManager.getReference(bean, beanClass, env);
  }

  private BeanManger getBeanManager()
  {
     if (_cdiManager == null) {
        try {
           InitialContext ic = new InitialContext();
           _cdiManager = (BeanManager) ic.lookup("java:comp/BeanManager");
       } catch (Exception e) {
           throw new RuntimeException(e);
        }
    }

    return _cdiManager;
  }
}

Once you have this utility code, you can migrate your service to CDI without asking permission from the rest of the framework. Use this CandiUtil.getReference method to create your main service instance once, and all of its dependencies will be CDI-enabled. In an agile-style short release cycle, you can easily add this CandiUtil in one cycle and migrate the service itself bit-by-bit in following cycles.

It’ll be interesting to see how @Inject is used in a project: will it be pervasive or used here and there in crucial places.

On the minimal end, @Inject could be restricted to resources like databases and large application services like a DAO manager. On the expansive end, someone could conceivably use @Inject as a “new” replacement, using it everywhere in every class. Based on the size of some Spring XML files, the maximal case might not be as unusual as it appears.

Picking the middle option is always the easy way out: it lets you look sensible and fair. Unfortunately, that vague moderation doesn’t really help when you’re making actual decisions.

I’d think anything large enough to be significantly tested or mocked would become an @Inject object. Certainly anything you could legitimately call a “service.” (And it’s a real shame that SOA overhyped the concept, because service-oriented design is a very useful architectural tool, and now it’s somewhat embarrassing to suggest structuring around services.)

Also anything configurable. And any extensions and plugins.

Beyond that, I’m not sure. Generally, I prefer wading into a new technology carefully to understand the issues before adopting it. @Inject as a JNDI replacement is a clear win as it big service injection. Beyond that, we’ll need real application experience.

As I’ve been working through the CDI TCK, and Emil and Reza are working through the EJB TCK, we’re seeing the same shared capabilities for both kinds of beans. Both CDI beans and EJB beans have the same aspects, which makes sense because they have the same cross-cutting concerns.

Conceptually, the aspects are all designed out of @Interceptors, which CDI/EJB supports in two flavors: EJB’s direct naming of the interceptor classes, and CDI’s declarative description using the @InterceptorBinding. CDI’s bindings are a bit more descriptive because your code says what it wants to do, named by the custom binding, not who is responsible for doing it like the EJB interceptor class.

In Resin, we’ve added the EJB custom aspects to any CDI bean, i.e. essentially any Java class, including servlets, filters, and JSF beans. The predefined aspects in EJB are:

• transaction boundaries: @TransactionAttribute
• security: @RolesAllowed, @RunAs
• async/messaging: @Asynchronous
• locks: @Lock
• and the custom @Interceptors and @Decorators

Over the last couple of weeks, I’ve been getting oriented with Jigsaw, seeing the progress they’re making and wondering how this work will affect our Java EE world. Though I still have a few questions remaining, I’ve found the high-level concepts to be very impressive. Moreover, the language-level approach that Jigsaw is taking is well-suited to integration with Java CDI. As you may know, Caucho is a major supporter of the Java CDI spec and we’re working on our own implementation, called CanDI. In this blog post, I’ll talk about the cool parts of Jigsaw and sketch a proposal for how Jigsaw and CDI might work together in the future.

(more…)

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