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.

@Service-EJBs bei JBoss — EJB 3.1 ruft

Bei JBoss ist eine Service-Bean eine besondere EJB, wovon es serverseitig nur ein Exemplar gibt.
Unterschiedliche Clients werden immer mit dem gleichen Exemplar arbeiten.
Es ist ein Singleton, ein nicht gepooltes Objekt.
Eine Service-Bean wird mit @org.jboss.annotation.ejb.Service annotiert.

@Service
public class VitalityCheckBean implements…

Über @Remote und/oder @Local wäre sich auch ganz normal von außen zugänglich.

Interessant sind Service-Bean, weil sie an einem MBean-Server angemeldet werden können und so über JMX zugänglich sind.
Dazu muss die EJB
mit @Service annotiert werden,
ein Management-Interface für die JMX-Operationen implementieren und
mit der Annotation @org.jboss.annotation.ejb.Management das Management-Interface benennen.
Das Management-Interface ist eine ganz normale Java-Schnittstelle und muss keiner Namenskonvention folgen.
Alle dort genannten Methoden sind über eine JMX-Konsole sichtbar.

interface MyManagementInterface
{
void doIt();
String getValue();
void setValue( String string );
}

import org.jboss.annotation.ejb.*;

@Service
@Management( MyManagementInterface.class )
public class SimpleServiceBean implements MyManagementInterface
{
private String string = „(default)“

public void doIt() {
System.out.println( „Ausgabe“ );
}

public void setValue( String string ) {
this.string = string;
}

public String getValue() {
return string;
}
}

In der JMX-Konsole unter http://localhost:8080/jmx-console/ suchen nach SimpleServiceBean mit ManagementInterface.

Der JMX-ObjectName lässt sich über das Attribut objectName der Annotation @Service ändern:
@Service(objectName=“javatutor:service=SimpleServiceBean“)
@Management(MyManagementInterface.class)
public class SimpleServiceBean implements …

Weiteres, auch zum Lebenszkylus unter