undefined is not a function

Unit-Testing EJB 3.1 with Netbeans, Maven and embedded Glassfish

2011-06-05T04:15:00.000-07:00

When trying out unit-testing support in Netbeans 7.0 with the EJB 3.1 embedded container from glassfish 3.1 I ran across a few problems for which I want to share my solutions. I'm working through chapter 6 of "Beginning Java EE 6 with GlassFish 3" at the moment. It's a good book but the code examples are not quite complete in some cases.

I'm in an Maven EJB Module-Project in Netbeans using:

Netbeans 7.0
GlassFish Server Open Source Edition 3.1 (43)
maven 3.0.3 (bundled)

The module is just a scaffold consisting of:

A JPA entity bean (provider: Eclipselink 2.0.2, jdbc: Derby 10.6.2.1 client)
An EJB implementing CRUD on this bean
A remote interface for the EJB
A web service

My goal is to test the EJB with the EJB 3.1 embedded container


EJBContainer.createEJBContainer()

First of all, when you generate an unit test for the EJB in Netbeans and use the provided quick fix for missing EJBContainer, it modifies the pom.xml to use the so-called Glassfish static shell for the embedded container.


<dependency>
  <groupId>org.glassfish.extras</groupId>
  <artifactId>glassfish-embedded-static-shell</artifactId>
  <version>3.1</version>
  <scope>system</scope>
  <systemPath>${glassfish.embedded-static-shell.jar}</systemPath>
</dependency>

It then sets the property ${glassfish.embedded-static-shell.jar} to a Glassfish installation of your choice, for example the bundled one. The jar file contains nothing but classpath entries for the jars needed for Glassfish embedded. This is suboptimal, as the build is now dependent on a local installation in the right version, and is not portable due to the hard-code path in the property. When using Hudson or similar CI, having to have a Glassfish installation on your build server is sometimes not preferable.

Alternatively, you can specify to download an embedded glassfish installation with the following pom.xml snippet:


<dependency>
  <groupId>org.glassfish.extras</groupId>
  <artifactId>glassfish-embedded-all</artifactId>
  <version>3.1</version>
  <scope>test</scope>
</dependency>

Warning: This is a big download, around 70 MB.

It works out of the box for simple EJB, but I still had a few issues in my case:

As soon as you put a remote interface in your bean, the embedded glassfish container starts a CORBA IIOP listener on default port 3700, resulting in a BindException: Address already in use if there is another instance of glassfish running
As soon as you put a JAX-WS web service in your bean, the embedded container throws a java.lang.NullPointerException at java.util.PropertyResourceBundle.handleGetObject(PropertyResourceBundle.java:136)
The embedded container can't find your JTA jdbc resources referenced in persistence.xml. I also wanted to use a different persistence.xml using an embedded Derby database and using drop-and-create for eclipselink.ddl-generation

To solve issue 1, I needed to use a different domain.xml than the default one for the embedded container to change the port numbers. Pointing the embedded container to a different domain.xml by putting the property org.glassfish.ejb.embedded.glassfish.configuration.file in a map and passing it to EJBContainer.createEJBContainer() as indicated by the Oracle GlassFish Server 3.1 Embedded Server Guide didn't work for me. Instead i had to use the org.glassfish.ejb.embedded.glassfish.instance.root, and point it to a glassfish domain directory. I have created it under src/test/resources/testing-domain. The following files are needed:

config/admin-keyfile
config/cacerts.jks
config/domain.xml
config/keyfile
config/keystore.jks
config/login.conf
config/server.policy

I pulled the files from the glassfish-embedded-all-3.1.jar and changed to domain.xml to use different port. I also activated the http and https listeners (putting them on ports 28080 and 28181, respectiveley).

To solve issue 2, I had to put the property org.glassfish.ejb.embedded.glassfish.web.http.port when calling EJBContainer.createEJBContainer(props);
The name of the property is a bit misleading, as the value is ignored completely and can be an empty String. It just means that the embedded glassfish instance should start the http listeners (just putting them as enabled="true" in domain.xml wasn't enough).

To solve issue 3, I created an additional persistence.xml and put it to src/test/resources/META-INF:


<?xml version="1.0" encoding="UTF-8"?> 
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"> 
  <persistence-unit name="bookstore-ejb" transaction-type="JTA"> 
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider> 
    <exclude-unlisted-classes>false</exclude-unlisted-classes> 
    <properties> 
      <property 
        name="eclipselink.target-database" 
        value="DERBY" /> 
      <property 
        name="eclipselink.ddl-generation" 
        value="drop-and-create-tables" /> 
      <property 
        name="eclipselink.logging.level" 
        value="FINE" /> 
      <property 
        name="javax.persistence.jdbc.driver" 
        value="org.apache.derby.jdbc.EmbeddedDriver" /> 
      <property 
        name="javax.persistence.jdbc.url" 
        value="jdbc:derby:memory:bookstore-ejb;create=true;" /> 
      <property 
        name="javax.persistence.jdbc.user" 
        value="APP" /> 
      <property 
        name="javax.persistence.jdbc.password" 
        value="APP" /> 
    </properties> 
  </persistence-unit> 
</persistence>

Next, I copy target/classes to target/embedded-classes and afterwards copy target/test-classes to target/embedded-classes to overwrite my production META-INF/persistence.xml with the maven-resources-plugin:


<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.5</version>
    <executions>
        <execution>
            <id>copy-classes-to-embedded</id>
            <phase>compile</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>target/embedded-classes</outputDirectory>
                <overwrite>true</overwrite>
                <resources>
                    <resource>
                        <directory>target/classes</directory>
                    </resource>
                    <resource>
                        <directory>src/test/resources</directory>
                    </resource>
                </resources>
            </configuration>
        </execution>

    </executions>
</plugin>

</plugins>

Then, I point the EJBContainer.MODULES property to target/embedded-classes.

We can now write our unit-test like this:


public class BookEJBTest { 

    private static EJBContainer ec=null; 
    private static Context ctx=null; 

    public BookEJBTest() { 
    } 

    @BeforeClass 
    public static void initContainer() throws Exception { 
        Map<String, Object> props=new HashMap<String, Object>(); 
        props.put(EJBContainer.MODULES, new File("target/embedded-classes")); 
        props.put("org.glassfish.ejb.embedded.glassfish.instance.root","./src/test/testing-domain"); 
        props.put("org.glassfish.ejb.embedded.glassfish.web.http.port",""); 
        ec = EJBContainer.createEJBContainer(props); 
        ctx = ec.getContext(); 
    } 


    @AfterClass 
    public static void closeContainer() throws Exception { 
        if(ctx!=null) 
            ctx.close(); 
        if(ec!=null) 
            ec.close(); 
    } 

    @Test 
    public void shouldCreateABook() throws Exception { 

        Book book = new Book(); 
        book.setTitle("The Hitchhiker's Guide to the Galaxy"); 
        book.setPrice(12.5F); 
        book.setDescription("Scifi book created by Douglas Adams"); 
        book.setIsbn("1-84023-742-2"); 
        book.setNbOfPages(354); 
        book.setIllustrations(false); 

        BookEJB bookEJB = (BookEJB) ctx.lookup("java:global/embedded-classes/BookEJB!de.familienservice.bookstoreejb.BookEJB"); 

        book = bookEJB.createBook(book); 
        assertNotNull("ID should not be null", book.getId()); 
    } 

}

The test runs with mvn test as well as with the embedded test runner in Netbeans 7.0. The build is portable und should run in my Hudson now.
Note that I didn't create a test for the webservice yet. The URL the webservice binds to is always http://localhost:28080/... though, so this should be an easy task.

FYR, I have put up the code for this project on github.

If you have any questions or tips for me, feel free to comment :-)

Edit: You have to have the glassfish maven repository in addition to the eclipselink repository in your pom.xml

   <repositories>  
     <repository>  
       <url>http://ftp.ing.umu.se/mirror/eclipse/rt/eclipselink/maven.repo</url>  
       <id>eclipselink</id>  
       <layout>default</layout>  
       <name>Repository for library Library[eclipselink]</name>  
     </repository>  
     <repository>  
       <id>glassfish-repo</id>  
       <url>http://download.java.net/maven/glassfish/</url>  
       <name>Repository for glassfish artifacts</name>  
     </repository>  
   </repositories>

Introducing Ext.direct to Netzke

2011-02-04T03:36:00.000-08:00

Ext.direct is a Sencha Ext JS standard API for communication with a server. The spec defines a protocol and expected behavior for server-side implementation. On the client-side, there are three adaptors making use of this API: the Ext.direct.RemotingProvider for doing RPC, the Ext.direct.PollingProvider for doing server-side push functionality and Ext.direct.JsonProvider for simple JSON APIs. There are also plans to implement a long-polling provider by the community, and I can imagine someone would want to write a WebSockets-based provider for server push in the future.
My work on Netzkes netzke-core (direct branch) changes the mechanism to make endpoint-RPC to a Ext.direct.RemotingProvider-based solution, completely preserving the API for endpoint calls.
This has multiple advantages:

Multiplexing/batching of RPC requests and responses
This is the main reason I thought Ext.direct could be useful for Netzke. While developing our application, we noticed that there is always a trade-off to be made between clean component-oriented design and technical considerations.
Technically, it is very bad to make multiple HTTP requests to the server for a single user action for obvious reasons.
Now imagine an action is invoked in the client which causes (server-side) state-changes for multiple components, like needing to refresh two GridPanels at once. From a purely component-oriented standpoint, every component should be completely encapsulated in a way that only the component needs to know what to do on the server for a specific action. For example, I want the GridPanel to reload its data and the component handles the server communication transparent to the caller, because it is an implementation detail of the component. Now in our scenario, this would result in to two requests, because I tell two GridPanels to reload the data, and let them handle it (also, it's very possible that they are customized and have some slightly different ways to achieve the reloading).
However, to solve the technical requirement "only one HTTP request per user action" the caller can't use this approach. Instead, it needs to send the server a special message "reload these two GridPanels", needs to dispatch the requests to the GridPanels on the server side, collect the results and afterwards dispatch the response to the client-side components. For this, it needs to know some implementation details of the GridPanels, which is contradictory to the principle of encapsulation in an component-oriented/OOP approach.
The multiplexing feature of Ext.direct solves this issue. With it, components can make endpoint calls which will get collected within a configurable timeframe (default: 10ms), and sent in a batch in a single HTTP requests to the server, preserving the order of the calls. The server can then dispatch the single requests and collect the result, and send a single response with the batched results, again in the order the original requests will be made. Ext.direct also handles the dispatching on the client side.
This allows us now to keep our components strictly encapsulated and make as many requests to the server from within the components as we want, without needing to check if some other component in the current composition also makes requests.

Fault-tolerance and tracking of transactions
Ext.direct assigns an transaction id per RPC and expects the server to include the transaction id in responses. This way the Ext.direct client can track ongoing transactions, can time the connections out in a controlled way (default timeout: 30s) and can retry the transaction in case of a packet loss or server fault (defaults to 3 attempts). Future improvement could be the tracking of transaction id on the server side, to make sure every transaction get's only executed once to prevent accidental multiple mutations of server state in case only the response gets lost on the wire. I haven't found a solution for this that doesn't involve an ever-growing list of transaction ids already processed that would make the heap explode eventually :-)

Possible extension point for future functionality
There is other functionality possible with Ext.direct, like the already mentioned server push mechanisms. I'm also in anticipation to see a long-polling or WebSockets implementation for Ext.direct.

Drawbacks
However, the current mechanism involving directly passing an endpointUrl() to Ext components won't work any more. Good news is, every component that takes an url: config (like stores) can be rewritten to use api: or directFn: configuration pointing to the generated endpoint (or can be replaced by specialized components like DirectStore).
I suggest that endpointUrl will be deprecated (the old way of accessing endpoints will still work, but won't benefit from Ext.direct).
I already modified netzke-basepack (also in direct branch) to make use of the Ext.direct provider in GridPanel, FormPanel, PagingFormPanel and Combobox. These are all places in basepack where endpointUrl was used. You should check the related changes in basepack and do them for your own app.

The current state of my work is "almost finished". It's passing the current netzke-core and netzke-basepack cucumber test-suites, but is missing tests for the specific Ext.direct functions (batching, controlled timeout and retry). Also it's missing configuration for delay timeframe of requests, timeout and retry count. In the end, it wasn't a lot of change but with considerable advantages (IMHO).

Demo
I have put together a small demo showing automatic request batching. It consists of two GridPanels and a single action, which adds a row to each of them. First, I show how it looks like in the current master branch. Then, I check out my direct branch and do the test again, and the number of requests is decreased.

Demo: Ext.direct in Netzke from Paul Schyska on Vimeo.

I appreciate any comments and suggestions, and feel free to fork me on github and follow me on Twitter :-)