Adam Bien

Lean Java EE 6 Without Spring And Spring 3.0 In Java EE 6 World: Summary and Conclusion (eJug Session)

admin — Mon, 6 Jul 2009 08:55:03 +0100

It turned out, that both components models are surprisingly similar. You could migrate an EJB 3.1 based application, almost without any additional effort to Spring (search and replace for annotations). It is even possible to run an EJB 3.1 applications without ANY modification just tweaking Spring a bit.

Although both technologies are almost identical from the programming model perspective - the philosophy is totally different. Spring "is not just a glue-framework" (Juergen clarified that), rather than complete solution - the full stack. Spring was architected as a layer above the actual application server. The idea: you can upgrade your APIs updating Spring and not touching the application server. This is especially important if you have to use the "heavyweights" application servers (=they come with at least with one DVD to install and the installation takes several hours :-)) without having any control about the version. The Dependency Injection is only a small part of the framework. Spring offers you from DI, over Spring MVC with REST support (similar to JAX-RS) and even monitoring. It actually replaces the most parts of the application servers with own services.

What was also interesting - Spring is exactly NOT Convention Over Configuration. The idea is to configure everything is needed explicitly, without relying on conventions. But you don't have to configure everything over and over again - you can use "Stereotypes" for that purpose. Stereotypes are "Meta-Annotations". So you can introduce your own annotations, using "annotation inheritance". Then you only will have to use your own shortcuts (e.g. @Service, @ServiceFacade etc.).

The philosophy of EJB 3.1 is exactly the opposite. It is not a complete solution, rather than "only" a component model for transactional, serverside applications. It comes with a set of suitable conventions, so you don't have to configure anything an rely on the existing conventions. Neither annotations (except @Stateless), nor XML-configuration is needed. The EJB infrastructure has to be available at the application server - so you only have to deploy your application - without the EJB-"framework" (Glassfish EJB 3 container is about 700kB) bits. The DI are not as sophisticated as Spring's, JSR-299 or JSR-330, but actually absolutely sufficient for most projects (at least my projects :-)).

EJB 3.1 components are aimed to run directly on the server, without any indirections. This also means: you can only use EJB 3.1 in case your application server has support for it. But: I also saw some projects using openEJB container to run EJB 3.1 on tomcat :-). Whats also true: SAP, IBM Websphere, BEA Weblogic, Oracle OC4J, JBoss 4 and 5, openEJB / Geronimo and Glassfish v2 (+several others) comes already with EJB 3 support. In that case your components become vendor neutral. You can move them around, without changing any EJB 3.X setting (JPA is harder to port across different providers). You will, however, have to test them on different servers.

Spring will support parts of the Java EE 6 specification - except the @Stateless annotations :-). We (Juergen Hoeller, eJug audience and me) discussed a bit longer this issue. We have different opinions on this: If I were SpringSource, I would support @Stateless and few EJB 3.1 annotation to make the transition more easy. Juergen said it would be hard to support @Stateless in completely compliant way - and he would expect some criticism then. But: the differences could be documented - so there should be no problems as well at this point.

In the practice, however, the support issue may be important as well. It is more and more important to provide the support for the full stack from one company. I guess in future you will see SpringSource only (e.g. dm server), and Java EE 6 only solutions. These decisions will be not driven by technical, rather than political / strategic reasons. Imagine Spring will run on a commercial application server in production and something goes wrong. Such support issues could be really "exciting". Some of my involvements in the resolution of "multi-vendor J2EE-only" support cases were already funny enough in the past :-).

I hope this is a unbiased description of this event - otherwise please feel free to drop me an email or comment. The eJug meeting was well organized at a nice venue - the upcoming sessions are interesting as well. My (English) slides are based on some contents from my "Real World Java EE Patterns" book -the slides should be available for download from eJug. See the German (eJug) summary as well. Thanks Juergen Hoeller for the invitation!

Btw. I will cover some "extreme" EJB 3.1 / REST with Convention Over Configuration approaches in the upcoming Java Magazin (German only :-)).

How To Debug Unit Tests In Netbeans 6.7

admin — Thu, 2 Jul 2009 07:44:49 +0100

In Netbeans 6.7 you can invoke, and especially debug unit tests in the following way:

1. From test results:
- Invoke context menu on a given test and select 'Debug'

2. From project
- Select test file and choose "Debug->Debug Test File" from main menu or press Ctrl_Shift_F6 (on Mac Cmd_Shift_F6)

The way on how test are executed is changed right after 6.5, you may get more insight from http://www.netbeans.org/issues/show_bug.cgi?id=119922

Please also check http://www.netbeans.org/issues/show_bug.cgi?id=158812, to track the recent changes.

Thanks to Alexei Mokeev for providing this information - I was shortly before filing a P1 bug :-). In my opinion the Netbeans 6.5 way was more intuitive.

Netbeans 6.7 (prev. Netbeans 7.0) - For Clouds - Detailed Overview

admin — Tue, 30 Jun 2009 08:28:31 +0100

Netbeans 6.7 (7.0) features - detailed view (kenai, maven, javaee). Someone translated this article from German. Thanks for the translation!

If you want to try out kenai go to: http://kenai.com/projects/javaee-patterns/, or open "Kenai" Tab --> Open Project and enter: javaee-patterns.

Netbeans 6.7 (prev. Netbeans 7.0) Is Ready To Download

admin — Mon, 29 Jun 2009 16:21:36 +0100

You can download it from here. Btw. if you need some samples to test Glassfish v3 / Mercurial / EJB 3.1 / JPA / Java EE Patterns - you can check out (actually pull) some code from here: http://kenai.com/projects/javaee-patterns/. All tested with 6.7 the "Java" edition. Search for javaee-patterns in the Kenai tab.

EJB 3.1 And REST - The Lightweight Hybrid

admin — Mon, 29 Jun 2009 08:05:07 +0100

The Local / Remote interfaces in EJB 3.1 are optional. You can still, however, expose a Session bean as a RESTFul (JSR-311) service.


package com.abien.patterns.business.rest.boundary;

import com.abien.patterns.business.rest.control.Service;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Stateless
@Path("current")
public class ServiceFacade {

    @EJB
    Service service;

    @GET
    public String getDate(){
        return service.getCurrentDate().toString();
    }

}

The Service is just another, usual, @Local bean:


@Stateless
public class Service {

    public Date getCurrentDate(){
        return new Date();
    }
}

A ServiceFacade becomes available via REST, just denoting it with the JAR-RS annotations. Its both an EJB 3.1 and a REST-resource - it is available under http://localhost:8080/EJBRestHybrid/resources/current (tested with Glassfish v3 preview). It will return the current time as String (Mon Jun 29 08:19:32 CEST 2009). The additional @Stateless has the following advantages:

Injection capabilities: you can easily inject other EJBs, EntityManagers, JMS-resources, DataSources or JCA connectors
Transactions: all changes made in a REST-call will be automatically and transparently synchronized with the database
Single threading programming model -> the old EJB goodness.
Monitoring: an EJB is visible in JMX
Throttling: its easy to restrict the concurrency of an EJB using ThreadPools or bean pools
Vendor-independence: EJB 3 runs on multiple containers, without any modification (and without any XML in particular :-))

Exposing a protocol-neutral ServiceFacade directly via REST can make it REST-dependent. E.g. you may pass JAXB-enabled classes as parameters / return - values. It will be hard then to expose the ServiceFacade through other channels. On the other hand - if REST is all you need, it is the simplest and leanest approach. There are no additional libraries needed - everything is already included in a Java EE 6 container (in Glassfish v3 the whole EJB 3.1 container is < 1 MB...).

The whole example project (tested with Netbeans 6.7rc3 and Glassfish v3 Preview) with source code was pushed into http://kenai.com/projects/javaee-patterns. In Netbeans 6.7 you will have to enable Glassfish v3 capabilities. If you are using vi or emacs :-), you will have to include the Java EE 6 API to the classpath.

[This sample is based on the ServiceFacade pattern from the "Real World Java EE Patterns" book]