I just extended Quercus to support the new core language features of PHP 5.4. The changes are currently in our subversion repository and should be in our next release: 4.0.34. Traits, new in 5.4, was a bit of a pain to implement because of all the weird edge cases (i.e. __CLASS__, insteadof, as). Here’s a list of what’s new:

• traits

  <?php
  
  trait T0 {
    function foo()
    {
      echo "inside T0->foo()\n";
    }
  }
  
  class A {
    use T0;
  }
  
  $a = new A();
  $a->foo();
  
  ?>
  

(more…)

The following article originally appeared on JavaAdvent 2012.

It’s been a 3.5 years ago to this day since I last wrote about running Quercus on Google App Engine (GAE). The article detailed a crazy experiment to get a PHP application, Wordpress, running on GAE. I still remember it being a painful experience because of number of changes I had to make to Wordpress to get it working. It was all due to the GAE Java environment being so drastically different from what Java developers were used to. It was heavily sandboxed and had no SQL support. You couldn’t launch new Threads. You couldn’t write to the file system. But those were the tradeoffs you had to live with if you wanted to deploy your application to the all-wonderful Cloud.

Fast-forward to 2012 and GAE has come a long way. GAE now allows you to spawn new Threads (currently in beta). You still cannot write to the file system, but for all it’s worth there is a new GAE Files API that gives you file-like concepts. And you can run your very own MySQL instances on Google’s infrastructure (albeit Google’s customized version of MySQL).

What hasn’t changed over the years is that you’re still expected to hit major roadblocks as you migrate your existing web applications over to GAE. And you’ll have to make heavy modifications to your application to 1) make it work and 2) be performant on GAE.

So this is where Quercus comes into the picture. At Caucho, we spent a lot of time getting Quercus to work seamlessly with GAE. Our goal was to abstract the GAE details away so that developers don’t have to worry about the fact that the application is running on GAE. Things just work transparently behind the scenes for PHP applications. For example,

• PHP file_*() functions work just like they do before (including writing to files!)
• PHP mysql_*() functions and PDO work just like they do before

(more…)

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

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