Archiv der Kategorie: Java EE

JPA-Beispiel in wenigen Minuten mit OpenJPA

  1. Beziehe unter http://mvnrepository.com/artifact/org.apache.openjpa/openjpa-all das openjpa-all-2.2.0.jar (etwas mehr als 6 MiB) und setzte es in den Klassenpfad.
  2. Habe einen Datentreiber im Klassenpfad (bei mir den der HSQLDB).
  3. Lege im Projekt einen Ordner META-INF an, platziere dort eine Datei persistence.xml:
  4. <?xml version="1.0" encoding="UTF-8"?>
    <persistence 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 persistence_2_0.xsd"
      version="2.0">
      <persistence-unit name="traida" transaction-type="RESOURCE_LOCAL">
        <class>traida.shared.domain.Contact</class>
        <properties>
          <property name="openjpa.jdbc.DBDictionary" value="hsql"/>
          <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:file:hsqldbtest;user=sa" />
          <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
          <property name="openjpa.Log" value="DefaultLevel=ERROR, Tool=ERROR" />
          <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema(ForeignKeys=true)"/>
        </properties>
      </persistence-unit>
    </persistence>

    Mehr zu den Properties unter http://openjpa.apache.org/builds/apache-openjpa-2.2.1-SNAPSHOT/docs/docbook/manual/main.html.

  5. Lege eine Klasse traida.shared.domain.Contact an:
  6. @Entity
    public class Contact {
      @Id
      @GeneratedValue( strategy = GenerationType.IDENTITY )
      public Long id;
      public String name;
      // Setter/Getter ausgelassen
    }

  7. Schreibe eine main(String[])-Methode mit:
  8. EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory( "traida" );
    EntityManager entityManager = entityManagerFactory.createEntityManager();
    entityManager.getTransaction().begin();
    Contact c = new Contact();
    c.name = "Hallo Willi";
    entityManager.persist( c );
    entityManager.getTransaction().commit();
    System.out.println( entityManager.createQuery( "select c from Contact c" ).getResultList() );
    entityManager.close();

  9. Fertig, jetzt freuen.

Erster Milestone von Jersey 2, implementiert JAX-RS 2

Weitere Details im Blog http://marek.potociar.net/2012/02/22/first-milestone-build-of-jersey-2-0/. Für Clients gibt es vielleicht die größte Änderung: Die Einführung der JAX-RS Client API. Die API ist allerdings noch nicht verabschiedet, kann sich daher also ändern. Die bisherige Spezi von JAX-RS liegt unter http://jcp.org/aboutJava/communityprocess/edr/jsr339/index.html.

GlassFish v3 und Java EE 6 freigegeben

Unter http://www.theserverside.com/news/thread.tss?thread_id=58858 ist heute zu lesen:

Sun has released the Java Platform Enterprise Edition 6and the GlassFish Enterprise Server v3.
Java EE 6 includes new specifications that add new functionality to the platform, like dependency injection, Bean Valiation and RESTful services, as well as improvements to the existing specifications including very significant improvements to Java Server Faces, Enterprise Java Beans, JPA, Servlets and Java Connectors. Java EE 6 also includes a Web Profile. Additional information on Java EE 6 is available from the WebSite and this Overview Article.
The GlassFish v3 Server implements the Java EE 6 specification. GlassFish v3 is Open Source and fully modular, built on an OSGi kernel and the Grizzly NIO infrastructure. GlassFish v3 is suitable for a wide range of applications, from development to deployments. The long list of additional GFv3 features includes embeddability, very fast startup, redeploy-on-save, session state persistence, dynamic language support, management and monitoring facilities, graphical, CLI and REST command interfaces, and an update center. GlassFish v3 is supported by NetBeans, Eclipse and IntelliJ IDEA.
Additional information on GlassFish v3 Server is available from the Product Page and our main Team Announcement. GFv3 can be downloaded here; the full version is 70MB and the Web Profile 50MB.

Zusammenfassung der Änderungen von EJB 3.1 und JPA 2

  • Die lokale Schnittstelle (local view) einer lokalen Session Bean kann nun entfallen, da direkt die öffentlichen Methoden als Schnittstelle verwendet werden können. Eine lokale Session Bean muss daher keine Schnittstelle mehr implementieren, um injiziert zu werden und Methoden anzubieten.
  • EJBs müssen nicht mehr in einem EAR-Archiv verpackt sein, sondern können einfach in einem WAR deployed werden. Im Fall von WAR-Archiven liegen dann die Klassen unter WEB-INF/classes.
  • Mit der Annotation @Singleon lässt ein Singleton markieren, sodass sich eine Session Bean (die auch Business Schnittstellen implementieren kann) von unterschieden Stellen nutzen lässt, aber eben nur einmal in der JVM vorhanden ist.
  • Die Annotation @Startup ist ein Zusatz für @Singleton, um über das Hoch-/Runterfahren des Applikationsservers informiert zu werden. Die Callbackmethoden nutzen das bekannte @PostConstruct und @PreDestroy.
  • Der EntityManager erlaubt ein detach().
  • Embeddable’s können in JPA 2.0 geschachtelt sein und Relationen eingehen.
  • Weitere Mappings bei JPA-Tabellen. Map-Keys können nun einfache Objekte, Entities und embedded Entities sein.
  • Bisher konnten etwa 1:n-Assoziationen immer nur Verweise auf Entity-Beans realisieren, aber keine Sammlungen etwa von Strings oder Datums-Objekten. Das ändert sich mit JPA 2.0, das Collections von Elementen erlaubt. Hier zieht JPA eine Collection-Table heran.
  • Die Entities im Persistence Context eines Entity-Managers sind in einem Cache, dem Level 1 Cache. Bei zwei Entity-Managern ist es implementierungsabhängig, wie zum Beispiel zwei gleiche Entity-Beans in den beiden EM gehalten werden. Das bestimmt ein Level 2 Cache. Dieser Level 2 Cache lässt sich über die Shared Cache API von JPA 2.0 rudimentär kontrollieren.
  • Mit einer @Version-Spalte erlaubt JPA 1.0 schon immer optimistisches Locking, allerdings nur optimistische Lese- oder Schreib-Sperren. Mit JPA 2.0 wird über die Enum LockMode nun Optimistisches und auch Pessimistisches Locking unterstützt.
  • Eine neue Criteria-API kommt in JPA 2.0 und damit neue Typen wie QueryBuilder, CriteriaQuery. Die API folgt dem Fluent-Interface Prinzip, etwa wie bei criteriaQuery.select(entity.get(„id“)).where(queryBuilder.cojunction(queryBuilder.equals(…), …)).
  • JPA-QL kennt für Datumswerte nun auch Literale.
  • JPA-QL unterstützt polymorphe Anfragen der Art WHERE CLASS(e) = Klassenname.
  • JPA-QL ermöglicht CASE-Anfragen wie eine Fallunterscheidung.
  • JPA-QL erlaubt in der WHERE-Klausel Zugriff auf den Index einer Liste.

JBoss 5 ist fertig + Application Servers 2008 Rankings

Nach 3 Jahren gibt es nun (endlich) den JBoss 5 AS. Einige Meldungen und Meinungen dazu:

JBoss 5 taucht aber (noch) nicht als zertifizierter Java EE 5 Container unter http://java.sun.com/javaee/overview/compatibility.jsp auf, obwohl http://sacha.labourey.com/2008/09/15/jboss-as-is-now-ee5-certified/ davon berichtet.

Unter http://www.theserverside.com/news/thread.tss?thread_id=51008 wird der EDC report – "Application Servers 2008 Rankings" (http://www.evansdata.com/reports/viewRelease_download.php?reportID=20) diskutiert. Die Kommentare sind lesenswert. Der Download des Papers verlangt ein Login, ist aber ansonsten frei.

Java EE 6 in der Endphase der Spezifikation

Die JSR-316 (http://jcp.org/aboutJava/communityprocess/edr/jsr316/index.html) ist eine Umbrella-API für Java EE 6. Am 22. November 2008 war der Close of Early Draft Review, sodass Java EE 6 nun in die heiße Endphase geht. Interessante neue APIs in Java EE 6 sind:

  • JSR-311 JAX-RS: Java API for RESTful Web Services
  • JSR-299 Web Beans
  • JSR-236 Timer for Application Servers
  • JSR-237 Work Manager for Application Servers

Erwartet Updates gibt es bei

  • Enterprise JavaBeans
  • Java Persistence API
  • Servlets
  • JavaServer Faces
  • JAX-WS
  • Java EE Connector API

Jersey 1.0 (JAX-RS) ist fertig

Im Sun-Blog ist http://blogs.sun.com/theaquarium/entry/jersey_1_0_just_shipped ist zu lesen:

JAX-RS co-spec lead and Jersey lead Paul Sandoz just announced Jersey 1.0 availability. v1.0 moments are always special and this one is certainly no exception given how progress was made on a regular basis from engineering hard work and lots of community feedback. Congrats to Paul and the entire community for a well run open source project !

Jersey 1.0 is obviously a JAX-RS 1.0 implementation, but it also adds Spring integration, a REST client, and obviously is production quality…
One of the signs of a community-involved project is the many ways the bits can be accessed: GlassFish v2 and v3, NetBeans 6.5, Maven 2, zip, etc…

With Jersey 1.0 out the door, you can now freely choose your Web Services style and stick to standards. Java EE 6, scheduled sometime mid-2009, will make this even clearer though a maintenance release.
See Jersey for more stories.

Und überall sitzt die OSGi Service Platform drunter…

Unter http://www.earthtimes.org/articles/show/world-leading-enterprise-application-server-providers,541827.shtml und http://www.osgi.org/blog/2008/09/impressive-press-release.html führen die Autoren auf, wie beliebt mittlerweile OSGi als Basis für Java EE Container ist. Peter Kriens führt folgende Container auf:

  1. IBM Websphere. They started in 2006 and aggresively moved their code on OSGi. Obviously it helped that IBM has committed itself to OSGi since day -1.
  2. Oracle WebLogic. Formerly known as BEA weblogic. BEA was one of the first companies public touting the advantages of OSGi, clearing the road for others.
  3. Paremus Infiniflow. Paremus has pioneered the use of OSGi in highly distributed application servers allowing the system to scale to unprecendented heights.
  4. ProSyst ModuleFusion. ProSyst is the key provider of OSGi technology in the embedded worlds but originated from the development of a J2EE server. They are now back in this market with an offering based completely on OSGi.
  5. Redhat JBoss. JBoss already worked with a microkernel approach but recognized the advantages of a standard two years ago.
  6. SAP Netweaver. Well, they are not yet based on OSGi, but they clearly see their future based on the OSGi specifications and are becoming more and more active in the OSGi Alliance.
  7. SpringSource Application Platform. The company that simplified Enterprise development with their Spring Framework decided to create their own offering in the application server market completely based on the OSGi specifications.
  8. Sun Glassfish. And last, but definitely not least, Sun decided to use OSGi in the JEE reference implementation Glassfish. They clearly take OSGi extremely serious nowadays since they also hired Richard S. Hall. It is so good to see Sun back at the OSGi Alliance.

Interessant sind zwei Feststellungen:

  1. In der Regel geben die Container die OSGi-Implementierung nicht nach oben weiter, abstrahieren also von den Internas. Nur einige Produkte erlauben, auch selbst OSGi-Bundles anzumelden.
  2. Java EE und das SpringFramework sind beides Nutznießer der OSGi-Plattform. Man kann nun fragen, ob man sich überhaupt noch mit OSGi selbst beschäftigen muss, wenn etwa GlassFish oder http://www.springsource.com/products/suite/applicationplatform gute Abstraktionen bieten.

HOWTO Add a JDBC DataSource/JNDI to GlassFish

Use asadmin with option create-jdbc-connection-pool first:

asadmin create-jdbc-connection-pool --datasourceclassname org.apache.derby.jdbc.EmbeddedDataSource --property databaseName=\$\{com.sun.aas.instanceRoot\}/databases/tutegodb:connectionAttributes=\;create\=true tutegoPool

Use asadmin again to install the actual JNDI name:

asadmin create-jdbc-resource --connectionpoolid=tutegoPool jdbc/tutego

To remove the pool and all attached JNDI names:

asadmin delete-jdbc-connection-pool --cascade tutegoPool

DZone-Interview mit Sacha Labourey über JBoss AS 5

Gibt es unter http://java.dzone.com/videos/tech-chat-sacha-labourey-jboss.

Natürlich galt es im Interview zu klären, warum man auf JBoss 5 so lange warten muss. Fertig ist er aber immer noch nicht!

We are very close to GA.

Warum noch immer nicht soweit? Weil der JBoss einen ganz neuen Microcontainer bekommt und weil unter anderem die Messaging-Lösung (JBoss Messaging) neu entwickelt wurde und JBoss 5 einen neuen Transaktions-Monitor bekommt. Einen Lacher erntet er bei mir aber mit:

Intuitively people usually think that it is an issue with the J2EE spec and how much time it took us to implement this pretty significant update of the J2EE spec.

JBoss war immerhin einer der ersten Container, die EJB 3 unterstützten. Aber Web-Services machen den JBoss 4 immer etwas Probleme, was auch an der Integration von Axis lag.

Ich sehe eher weniger gute Zukunfsaussichten für JBoss. Mit der wachsenden Popularität von GlassFish und Geronimo wird JBoss 5 zu kämpfen haben. GlassFish und Geronimo/IBM WASCE sowie WebLogic Server v10.0, SAP NetWeaver 7.1, Apusic Application Server, TmaxSoft JEUS 6, NEC WebOTX 8.1 sind (zum Teil schon sehr lange) Java EE 5 zertifiziert (http://java.sun.com/javaee/overview/compatibility.jsp) und JBoss 5 hat das auch noch vor sich.

Weiterhin glaube ich in der Java-Community einen Trend in Richtung der Sun-Implementierungen erkennen zu können, was zum Beispiel die RI für JavaServer Faces, aber auch etwa JAX-WS für Web-Services angeht. Interessant ist auch, dass GlassFish die JSP-Servlet-Übersetzung optimiert über JSR 199 regelt, eine Entwicklung, die eben nicht von Tomcat ausgeht. So nutzt auch Jetty das. (Schon 2006 war zu lesen: "patch to allow Jetty to use JSP2.1 from Glassfish instead of Jasper from Tomcat"). Von GlassFish geht im Moment ein sehr starker Zug aus und es bleibt sehr spannend.

Neues aus EJB 3.1

Einige Änderungen aus dem Preview der EJB 3.1 Specification.

Es gibt neu auch Singleton Session Beans, die mit @Singleton annotiert sind:

The EJB specification defines stateful, stateless, and singleton session beans. There are differences in
the API between stateful session beans, stateless session beans, and singleton session beans.

4.7 Singleton Session Beans
A Singleton session bean is a session bean component that is instantiated once per application. In cases
where the container is distributed over many virtual machines, each application will have one bean
instance of the Singleton for each JVM.
Once instantiated, a Singleton session bean instance lives for the duration of the container in which it is
created. It maintains its state between client invocations but that state is not required to survive container
shutdown or crash.

Man kann für lokale Beans auf eine Business-Schnittstelle verzichten:

In EJB 3.x, a local client accesses a session bean through the bean’s local business interface or through
a no-interface client view representing all the public methods of the bean clas
s.

3.4.2 Obtaining a Reference to the No-interface Local View
A client can obtain a reference to a Session Bean’s No-interface Local View through dependency injection
or lookup in the JNDI namespace.
For example, the No-interface Local view of the CartBean session bean with bean class com.acme.Cart-
Bean may be obtained using dependency injection as follows :
@EJB CartBean cart;
The CartBean No-interface view could also be looked up via JNDI as shown in the following code segment
using the lookup method provided by the EJBContext interface. In this example, a reference to
the client bean’s SessionContext is obtained through dependency injection:
@Resource SessionContext ctx;

CartBean cart = (CartBean)ctx.lookup(“cart”);
Despite the fact that the client reference for the No-interface Local view has type <bean class> , the client
never directly uses the new operator to acquire the reference.

3.4.4 Session Bean’s No-Interface Local View
A Session Bean’s no-interface view is a variation of the Local view that exposes the public methods of
the bean class without the use of a separate business interface.
A reference to the no-interface view may be passed as a parameter or return value of any Local business
interface or no-interface view method.
The container provides an implementation of a reference to a no-interface view such that when the client
invokes a method on the reference, the business method on the session bean instance and any interceptor
methods are invoked as needed.
Only public methods of the bean class (and any super-classes) may be invoked through the no-interface
view. Attempted invocations of methods with any other access modifiers via the no-interface view reference
result in the javax.ejb.EJBException.
It is invalid to reference a session object that does not exist. If a stateful session bean has been removed,
attempted invocations on the no-interface view reference result in the javax.ejb.NoSuchEJBException.

Neu ist, das eine Session-Bean synchron oder asynchron aufgerufen werden kann:

3.4.8 Asynchronous Invocations
By default, session bean invocations through the Remote, Local, and no-interface views are synchronous,
meaning the client blocks for the duration of the invocation and is returned control only after all
invocation processing has completed. Clients can achieve asynchronous behavior by invoking session
bean methods that have been designed to support asynchrony.

When a client invokes an asynchronous method, the container returns control to the client and continues
processing the asynchronous invocation on a separate thread of execution.

3.4.8.1 Return Values
Asynchronous methods have a return type of void or Future<V>, where V represents the result value
of the asynchronous invocation.
In the case of a Future<V> return type, the object returned to the client is a container provided object.
This object allows the client to retrieve the invocation result value, discover any invocation exception,
or attempt to cancel the asynchronous invocation.

Java EE 6 — das Spiel geht weiter

Es war klar, dass es nach der Java EE 5 ein Java EE 6 geben wird. Nun wurde die neue JSR 313: JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification ausgerufen. Teil der Java EE 6 wird sein:

  • JSR-196 Java Authentication SPI for Containers
  • JSR-236 Timer for Application Servers
  • JSR-237 Work Manager for Application Servers
  • JSR-299 Web Beans
  • JSR-311 JAX-RS: Java API for RESTful Web Services

Auf Web-Beans bin ich gespannt, denn da gehen die Ideen von JBoss Seam ein, also EJB 3 und JSF zu verheiraten.

Aktualisiert werden laut Standard:

  • Enterprise JavaBeans
  • Java Persistence API
  • Servlets
  • JavaServer Faces
  • JAX-WS

Und Verschoben sind:

  • JSR-168 Portlet Specification
  • JSR-170 Content Repository for Java technology API
  • JSR-207 Process Definition for Java
  • JSR-208 Java Business Integration (JBI)
  • JSR-225 XQuery API for Java (XQJ)
  • JSR-235 Service Data Objects
  • JSR-286 Portlet Specification 2.0
  • JSR-289 SIP Servlet v1.1
  • JSR-301 Portlet Bridge Specification for JavaServer Faces

Das Release ist für das 3 Q 2008 angedacht. Viel Zeit also noch.