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.

The way that you start and stop Resin and the watchdog have changed a bit in the 4.0 branch. I realized as I was writing the Resin Refcard that there are probably a few options and concepts that many users don’t fully understand. In this post, I review the Resin watchdog architecture and show the syntax while highlighting recent changes. I’ll also describe some of the thoughts we have for the future of the watchdog and solicit your ideas and input.

(more…)

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

I gave a talk Wednesday at the Silicon Valley Google Technology Users’ Group on using Quercus in the App Engine. One of the examples I gave was using the low-level data API from PHP and scheduling PHP “tasks” using Task Queues. I’ll walk through the source of that demo here to give you an idea of how Quercus makes it easy to mesh a Java platform with PHP code. At the end, I’ll also give you an idea of what the next steps would be to take this demo and use the techniques in a real application or framework.
(more…)

Since unit testing and test-driven development have become accepted as the basis for solid programming practices, we’ve had several requests to provide a lightweight Resin environment specifically tailored to test environments. As our first cut, we’ve created a ResinBeanContainer class, usable outside of Resin, but providing a Resin environment.

The ResinBeanConstainer provides the same environment as a Resin web-app, but without the servlets, HTTP or requests. It provides CDI injection, EJB lite support, database and JPA configuration.

(more…)

Sample JVM Graph from Resin Admin

We’ve been doing a lot of work on our Resin administration application over the last few releases, adding features like statistic graphs, postmortem reports, and REST. The framework we’re building for these features is also quite extensible and easy to use. One of the in-house extensions we developed combines the REST and graph features so that you can export and embed user-defined graphs. We’ve added this extension to the main application for the upcoming 4.0.4 release so it’s available without any coding. In this blog post, I’ll show you how to embed Resin statistics graphs in your own monitoring tools, how the underlying graph API works, and give some tips on how to write your own similar extensions.

(more…)

Joe Armstrong has a good argument for websockets as the next phase of web development at armstrong: Comet is dead long live websockets:

I think this means the death of the following technologies:

• comet
• long-poll
• AJAX
• keep-alive sockets

All the above are merely hacks, inadequate ways of programming round the central problem that web-browsers could not simply open a socket and do asynchronous I/O like any other regular application.

His example uses Erlang, but the same idea applies with Resin’s WebSocket support

Apache Chainsaw is a popular graphical logging tool for Java. Even though it’s based on Log4j and Resin’s logging uses java.util.logging, you can use Chainsaw to analyze Resin’s logs in real time. In this blog, I’ll show you how to connect Resin with Chainsaw using a technique that can be extended to other Log4j-based analysis tools.

(more…)

Starting with Resin 4.0.2 (due out within a week), the Resin administration application supports a REST interface for grabbing server information. In this blog post, I’ll give an overview of the REST interface, how to write plugins, and even how to integrate with Nagios.

(more…)

The Internet is becoming more and more about sharing data, and, uploading files had become nearly universal requirement for a web application. Prior to Servlet 3.0, implementing file upload successfully required external libraries or tedious input processing. Version 3.0 of the spec goes a long way towards providing us with a solution to the problem in a generic and portable way.
(more…)