Mit Hilfe von EJB3 können endlich Entity-Beans mit Hilfe von Annotations beschrieben werden. Nach der neusten und letzten Definition des Standards wird jetzt jedoch anhand der Stelle der Annotations (ob am Feld oder am Getter) entschieden womit der Persistenzmanager arbeitet. Dieses Verfahren darf jedoch nicht gemischt werden. Pro Entity muss man sich daher auf Field oder auf Getter festlegen. Anderenfalls kann es zu verwunderlichen Problemen kommen, die sich dann wie folgt äußern:

Caused by: java.sql.SQLException: Invalid column name 'createDate'.

Problem hierbei ist folgender Code:

@Entity
@Table(name = "customers")
public class Customer implements Serializable {

    private static final long serialVersionUID = 2005121501L;

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    @Column(name = “customer_id”)
    private int id;

    @Column(name = “customer_name”, nullable = false)
    private String name;

    private Date createDate;

    public int getId() {
        return id;
    }

    private void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Column(name = “create_date”, nullable = false)
    public Date getCreateDate() {
        return createDate;
    }

    public void setCreateDate(Date createdate) {
        this.createDate = createdate;
    }
}

Hier wird die Annotation über getCreateDate ignoriert, da für die Klasse eine Fieldinvocation gewählt wurde. Ausschlaggebend dafür ist bei der Hibernateimplementierung wo der @ID-Tag steht. Die Folge ist daher, dass das Feld

    private Date createDate;

implizit gemappt wird auf das Datenbankfeld “createDate”, welches nicht existiert.
EntityBeans sollten also mit größtmöglicher Sorgfalt überprüft werden.

Seit Version 4.0.4 und 3.2.8 ist es möglich Farm-Deployment auch für HASingletons zu nutzen. Dazu muss der Service einfach von folgendem Dienst abhängen:

jboss.ha:service=HASingletonDeployer,type=Barrier

Weitere Informationen dazu wurden auch im JBoss-Blog veröffentlicht.

Wie unter “MessageDrivenBeans auf EJB3 Manier” beschrieben, können entsprechende MDBs mit Annotations nach dem J2EE 5 Standard definiert werden. Dazu werden entsprechende Parameter über die ActivationConfig festgelegt. Dafür gibt es einige Paremtere, welche ich hier auflisten möchte.

Im JBoss Wiki sind einige Parameter aufgeführt. Dies betrifft die allgemeinen Parameter nach JCA 1.5 Spec, welche die notwendigen Parameter destination und destinationType definiert. JBoss selbst stellt zudem weitere mögliche Parameter zur Verfügung, welche vor allem sich auf die DLQ (DeadLetterQueue) und die Steuerung der Anzahl paralleler Verarbeitung, etc. regelt. Zudem habe ich im Forum noch zwei weitere Parameter gefunden, welche ich leider nicht weiter dokumentiert gesehen habe:

• minPoolSize - gibt die minimal zu verwendeten Threads an
• maxPoolSize - gibt die maximal zu verwendeten Threads an

Insgesamt sieht dies dann in der Java-Datei wie folgt aus:

@MessageDriven(activationConfig = {
        @ActivationConfigProperty(
                propertyName = “destinationType”,
                propertyValue = “javax.jms.Queue”
        ),
        @ActivationConfigProperty(
                propertyName = “destination”,
                propertyValue = “queue/MDB”
        ),
        @ActivationConfigProperty(
                propertyName = “minPoolSize”,
                propertyValue = “1″

        ),
        @ActivationConfigProperty(
                propertyName = “maxPoolSize”,
                propertyValue = “1″
        )
})

Im Rahmen von EJB3 werden natürlich auch entsprechende Interceptors zur Verfügung gestellt. Z.B. mit @PostConstruct kann man eine Methode definieren, welche nach dem Erstellen eines Beans (z.B. MessageDrivenBean) aufgerufen wird.

Nun kam aber diese Exception heraus:

java.lang.TypeNotPresentException: Type javax.ejb.PostConstruct not present
...
Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: javax.ejb.PostConstruct

Grund dafür ist, dass im Rahmen der Spezifikationsänderungen von Sun diese Annotations aus dem Package javax.ejb nach javax.annotation verschoben wurden. Bei JBoss zogen diese Änderung von EJB3 RC5 auf EJB3 RC6 ein.

Mit ein paar Tagen Verspätung, denn laut IssueTracker war der 12.05. geplant, wurde Heute endlich die Version 4.0.4 GA vom JBoss veröffentlicht. Für mich in erster Linie sehr interessant ist die Integration des neuen Webservice-Stacks JBossWS, womit die Realisierung von Webservices über Annotations nach JSR-181 möglich wird, sowie die nächste RC (RC7) der EJB3-Implementierung.

JBoss bietet von Haus aus die Möglichkeit EntityBeans zu cachen. Dazu muss man lediglich Hibernate und seine EntityBeans entsprechend konfigurieren. Vor allem bei sich selten ändernden Beans, wie z.B. Kategorien in einem Shop oder Länder / Sprachen, bietet sich das Caching durchaus an.
In der persistence.xml muss dazu lediglich der CacheProvider für Hibernate entsprechend konfiguriert werden:

<entity-manager>
    <name>mystore</name>
    <jta-data-source>java:/MyStoreDS</jta-data-source>
    <properties>

        <property name=“hibernate.hbm2ddl.auto“ value=“none“/>
        <property name=“hibernate.dialect“ value=“org.hibernate.dialect.MySQLDialect“ />

        <property name=“hibernate.cache.provider_class“ value=“org.jboss.ejb3.entity.TreeCacheProviderHook“/>
        <property name=“hibernate.treecache.mbean.object_name“ value=“jboss.cache:service=EJB3EntityTreeCache“/>

    </properties>
</entity-manager>

Im Property “hibernate.treecache.mbean.object_name” wird entsprechend der dahinter liegende TreeCache definiert.

Damit ein EntityBean auch wirklich in den Cache wandert, muss das Bean noch entsprechend zum Cachen markiert werden.

package com.itblogger.beans;

@Entity
@Cache(usage=CacheConcurrencyStrategy.READ_ONLY)
public class Category implements Serializable {
  int category;
  String categoryName;
}

Weitere Informationen dazu können der Dokumentation zu @Cache und CacheConcurrencyStrategy entnommen werden.

Der Cache selbst kann in der Datei ejb3-entity-cache-service.xml (unter server/default/deploy) oder bei einem eigenen TreeCache genau in dessen XML-Datei gepflegt werden.

<server>
    <mbean code=“org.jboss.cache.TreeCache“ name=“jboss.cache:service=EJB3EntityTreeCache“>
        <depends>jboss:service=Naming</depends>

        <depends>jboss:service=TransactionManager</depends>
        …
        <attribute name=“EvictionPolicyConfig“>
            <config>

                <attribute name=“wakeUpIntervalSeconds“>5</attribute>
                <region name=“/_default_“>

                    <attribute name=“maxNodes“>5000</attribute>
                    <attribute name=“timeToLiveSeconds“>1000</attribute>

                </region>
                <region name=“/com/itblogger/beans/Category“>
                    <attribute name=“maxNodes“>10</attribute>

                    <attribute name=“timeToLiveSeconds“>5000</attribute>
                </region>
            </config>

        </attribute>
        …
    </mbean>
</server>

Für jedes Bean können hier zusätzliche Cacheparameter eingestellt werden.

Sinn und Zweck von MessageDrivenBeans (MDB) ist es Nachrichten asynchron abzuarbeiten. Dazu schickt ein Client, wie z.B. ein SessionBean oder ein Servlet, eine Nachricht in eine Queue und diese verarbeitet dann Nacheinander oder mit Hilfe eines Threadpools auch parallel die Nachrichten. Dazu werden die Nachrichten an ein MDB übergeben und dieses Bean verarbeitet dies dann.
Wir benötigen also ein MDB, welches an eine Queue gehangen wird um die Nachrichten entgegen zu nehmen. Dazu erzeugen wir uns einfach eine Klasse und implementieren dazu noch das Interface MessageListener. Mit Hilfe der Annotations @MessageDriven deklarieren wir diese Klasse als MDB. Das Ganze könnte dann ungefähr so aussehen:

import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;

import javax.jms.JMSException;
import javax.jms.Message;

import javax.jms.MessageListener;

@MessageDriven(activationConfig = {
        @ActivationConfigProperty(propertyName = “destinationType”, propertyValue = “javax.jms.Queue”),
        @ActivationConfigProperty(propertyName = “destination”, propertyValue = “queue/A”) })

public class MessageDrivenTest implements MessageListener {
    public void onMessage(Message message) {
        System.out.println(“*********** RECEIVE MESSAGE **********”);
    }
}

Bei der Annotation MessageDriven definieren wir mit den Parametern ActivationConfig die Queue-Art wo wir uns anhängen und natürlich den Namen (JNDI-Namen), wo die Queue zu finden ist. Falls es keine Queue mit diesem Namen gibt, so legt uns JBoss beim Deployment automatisch eine entsprechende Queue an. Es sollte jedoch im Produktionsbetrieb die Queue weiter Konfiguriert werden, vor allem bezüglich Zugriffssicherheit und Persistenz. Dazu steht die Konfigurationsdatei deploy/jms/jbossmq-destinations-service.xml zur Verfügung.
Der Versand von Nachrichten erfolgt dann durch Verbinden zu der Queue und das entsprechende Absenden einer Nachricht.

import javax.jms.Queue;
import javax.jms.QueueConnection;

import javax.jms.QueueConnectionFactory;
import javax.jms.QueueSender;

import javax.jms.QueueSession;
import javax.jms.TextMessage;

import javax.naming.InitialContext;
import javax.naming.NamingException;

private void sendJMSMessage() {
    Queue queue;
    QueueConnection cnn;
    QueueSession sess;
    try {
        InitialContext ctx = new InitialContext();
        queue = (Queue) ctx.lookup(“queue/A”);
        QueueConnectionFactory factory = (QueueConnectionFactory) ctx.lookup(“ConnectionFactory”);
        cnn = factory.createQueueConnection();
        sess = cnn.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
        TextMessage msg = sess.createTextMessage(“Some Text”);
        QueueSender sender = sess.createSender(queue);
        sender.send(msg);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Vielleicht kennen Sie das, sie möchten eine große Anzahl hängengebliebener Prozesse killen, die sich jedoch nicht eindeutig über den Prozessnamen identifizieren lassen. Das ist nützlich z.B. bei Java oder Shell Prozessen. Hier müssen wir die Ausgabe von ‘ps’ geschickt nach dem gewünschten Suchwort greppen, per akw die Prozess-ID’s filtern um damit dann zb per xargs den kill Befehl aufzurufen:

ps x | grep shellscript.sh | awk ‘{print(substr($1,0,5))}’ | xargs kill -9

… ein ‘killall -9 shellscript.sh’ funktioniert in so einem Fall offensichtlich nicht.

HSDPA wird nun bald in größeren Städten verfügbar sein. Hiermit werden UMTS Downloads von bis zu 1,8 MBit / Sekunde möglich werden. T-Moblie Kunden können jetzt schon in den Genuss von HSDPA kommen.

Bei den .EU Sunrise Phasen sind bei den bis jetzt geprüften Anträgen ganze 32% abgelehnt worden. Diese Domains können nun ab dem 7. Juni wieder registriert werden. Hierzu wird die Eurid zwei Wochen zuvor eine genau Liste veröffentlichen. Auch hier gilt wieder: Wer zuerst kommt…