EJBs von Lift aufrufen

Lift ist das Web-Framework für Scala. Da Lift in WARs gepackt wird, sollte es kein Problem sein, von dort auf EJBs zuzugreifen. Hier in schneller Weg zum proof of concept mit Netbeans, maven, Lift und Glassfish 3:

Das Enterprise Projekt

Einfach mit Netbeans ein neues Projekt „Maven Enterprise Application“ anlegen. Als Projektnamen nehmen wir „hellolift“ und als Paket und GroupId „demo.hellolift“. Im folgenden Dialog verzichten wir aus das Web Modul, denn das wird mit Lift erstellt. Ein EJB Modul und das Ear Paket nehmen wir aber.

Lift Web Modul

Netbeans sollte jetzt einen Ordner „hellolift“ mit einer pom und Unterordnern für die Module erstellt haben. Dahin wechseln wir und bauen eine leere Lift Application aus dem Archetypen:

mvn archetype:generate -U  -DarchetypeGroupId=net.liftweb \
      -DarchetypeArtifactId=lift-archetype-blank -DarchetypeVersion=1.0 \
      -DremoteRepositories=http://scala-tools.org/repo-releases \
      -DgroupId=demo.hellolift -DartifactId=hellolift-war -Dversion=1.0-SNAPSHOT

Das sollte einen Ordner mit dem Web Modul erstellen.

Die EJB

Ok, die einfachste Bean die irgendetwas mach reicht für unser Beispiel:

package demo.hellolift;

import java.util.Date;
import javax.ejb.Local;
import javax.ejb.Stateless;

@Stateless
@Local(HelloEJBLocal.class)
public class HelloEJB implements HelloEJBLocal {

    public String sayHello(String name) {
        return "Hi " + name +" its's " + new Date().toString();
    }
}

und das Interface

package demo.hellolift;

public interface HelloEJBLocal {

    String sayHello(String name);
}

Wichtig ist hierbei dass die Local Annotation nicht im Interface steht, damit das „sauber“ bleibt.

Damit das Web Modul auch weiß, was es aufrufen soll, muss das EJB Pom noch erweitert werden:

(...)
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-ejb-plugin</artifactId>
    <version>2.1</version>
    <configuration>
        <ejbVersion>3.1</ejbVersion>
        <generateClient>true</generateClient>
        <clientExcludes>
            <clientExclude>demo/hellolift/*EJB.class</clientExclude>
        </clientExcludes>
    </configuration>
</plugin>
(...)

Damit wird ein EJB Client jar erzeugt, das nur das Interface enthält.

Lift Applikation

In dem Web Modul wird jetzt einfach das erzeugte HelloWorld Snippet in demo.hellolift.snippet angepasst:

package demo.hellolift.snippet

class HelloWorld {
  def getBean () = {
      val c = new _root_.javax.naming.InitialContext();
      val l = c.lookup("java:global/hellolift-ear/hellolift-ejb-1.0-SNAPSHOT/HelloEJB" +
                       "!demo.hellolift.HelloEJBLocal");
      l.asInstanceOf[demo.hellolift.HelloEJBLocal]
    }

  def howdy = <span>EJB says {getBean().sayHello("Lift Web") }</span>
}

Das JNDI-Name ist hier im Beispiel nach EJB 3.1 Standard. Und ja, das Programm kümmert sich nicht einmal um die Exception. 🙂 Jetzt brauchen wir noch die Abhängigkeit zum EJB Client jar und ergänzen das pom um:

<dependencies>
    <dependency>
        <groupId>demo.hellolift</groupId>
        <artifactId>hellolift-ejb</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>ejb-client</type>
    </dependency>
(...)
</dependencies>

Und alle zusammen…

Im übergeordneten pom muss das Web Modul eingetragen sein, was Netbeans aber schon für uns erledigt haben sollte. Jetzt muss nur noch dem EAR die Referenz auf das Web Modul mitgegeben werden:

<dependencies>
(...)
    <dependency>
        <groupId>demo.hellolift</groupId>
        <artifactId>hellolift-war</artifactId>
        <version>1.0-SNAPSHOT</version>
        <type>war</type>
    </dependency>
</dependencies>

Fertig. Das so erzeugt EAR lässt sich jetzt deployen. Man kann also ziemlich unproblematisch mit Lift auf ein bestehendes EJB Backend zugreifen.
Hier das erzeugteProjekt zum Runterladen und Selberspielen: hellolift.zip

Spring vs. Java EE reloaded

Java EE wird immer schlanker. Java EE 5 war schon ausgesprochen angenehm benutzbar durch den Einsatz von Annotationen. Java EE 6 legt noch einmal nach mit interfacelosen Beans. Eine der simpelsten 3 Tier Apps in Java EE 6 hat wohl Adam Bien gebaut. Gleichzeitig ist der EJB Container schlanker geworden und lässt sich jetzt embedded nutzen – also z.B. in Desktopapplikationen oder einfach im war mit deployed für einen reinen Web-Container wie Tomcat.

Es gibt endlose Implementationen des Standards – auch viele im Open Source Bereich. Insbesondere ist die Referenzimplementation Open Source.

Spring hingegen wird scheinbar immer unhandlicher. War Spring schon immer auch Wrapper über Wrapper und somit schon immer ein zusätzlicher Layer auf den man auch gerne mal verzichtet, war Spring gegenüber J2EE doch die bessere alternative. Seit dem Spring kommerzieller geworden ist, scheinen auch die Spring Befürworter langsam etwas skeptisch zu werden und fragen sich „Is Spring still lightweight“. Nebenbei ist Spring nach wie vor kein Standard und es gibt genau eine Implementation. Sieht so aus, als würde Java EE auch für die Spring Anhänger langsam interessanter.

Nachtrag:

In diesem Forum ist eine lustige und sehr emotionale Diskussion zu dem Thema entstanden.