Damit der JBoss nicht unter dem User ‘root’ läuft empfiehlt es sich einen eigenen User ‘jboss’ anzulegen und mit diesem den JBoss zu starten. Dazu muss diesem User der JBoss auch gehören:

# User 'jboss' hinzufügen
useradd jboss

# Diesem User das JBoss AS Verzeichnis geben
chown -R jboss:users /opt/jboss422/

Hier das eigentliche Startscript welches bei mir den Namen jboss422 vergeben bekommen hat und unter den meisten Linux Distributionen im Verzeichnis /etc/init.d/ abgelegt wird. Wie schon erwähnt liegt mein JBoss 4.2.2 im Verzeichnis /opt/jboss422, so dass dieser Pfad auch im Startscript verwendet wird:

#! /bin/sh

start(){
  echo "Starting jboss.."
  sudo -u jboss bash -c "/opt/jboss422/bin/run.sh --host 0.0.0.0 > /dev/null 2> /dev/null &"
  #/opt/jboss422/bin/run.sh --host 0.0.0.0 > /dev/null 2> /dev/null &
}

stop(){
  echo "Stopping jboss.."
  sudo -u jboss bash -c '/opt/jboss422/bin/shutdown.sh -S &'
  #/opt/jboss422/bin/shutdown.sh -S &
}

restart(){
  stop
  # give stuff some time to stop before we restart
  sleep 60
  # protect against any services that can't stop before we restart (warning this kills all Java instances running as 'jboss' user)
  sudo -u jboss killall java
  start
}

case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  *)
  echo "Usage: jboss {start|stop|restart}"
  exit 1
esac

exit 0

Hat man für den ersten Test keinen User ‘jboss’ oder möchte den JBoss unter dem User ‘root’ laufen lassen einfach die Zeile sudo -u jboss .. mit # auskommentieren und die darunter gelistete Zeile einkommentieren.

Jetzt fehlt noch das Hinzufügen des Startscriptes zu dem Bootprozess, so dass der JBoss mit jedem Serverstart auch automatisch gestartet wird. Der Teil ist optional, denn vielleicht möchte der ein oder andere den JBoss immer per Hand starten.

Unter Suse wird das Startscript mit dem Kommando chkconfic <scriptname> on hinzufügen:
chkconfig jboss422 on
Erstellt automatisch die Symlinks und aktiviert das Startscript

Unter Debian wie folgt:
update-rc.d jboss422 defaults
Erstellt automatisch die notwendigen Symlinks.

Uptime mit Hilfe des Startdatums herausfinden
Mit der MBean Server lässt sich erfahren wie lange der JBoss am laufen ist bzw. wann er gestartet wurde. Diese Information wird in der Liste der MBean Attributen unter dem Namen “StartDate” angezeigt:

Speicherverbrauch analysieren
Mit der MBean ServerInfo kann man in der Liste der MBean Attribute viele Informationen wie z.B. Total Memory, Host Address oder Java VM Version herausfinden. Interessanter für den Betrieb des JBoss AS ist aber vielmehr wie viel Arbeitsspeicher dem JBoss zur Verfügung gestellt wurde und wie viel davon bereits verbraucht ist.
Gerade während der Entwicklung arbeitet man viel mit Hot Deployment und ab und an erhält man die java.lang.OutOfMemoryError: PermGen space Exception. Um herauszufinden wieviel Perm Gen Space reserviert und bereits benötigt wird kann man in der ServerInfo MBean auf die Methode listMemoryPools() klicken und erhält unter anderem folgende Ausgabe:

Die zwei hier vorgestellten Funktionen sind während der Entwicklung aber auch während des Betriebes wirklich nützlich. Vor allem die Kombination Serverlaufzeit und Speicherverbrauch ist ein interessanter Faktor. Wird je der benötigte Speicher mit längerer Laufzeit immer größer sollte man nochmal über seine Anwendung nachdenken ;)

Vielleicht noch als letzte Anmerkung: mit dem auch unter jboss.system liegenden Log4JService kann man die unter dem JBoss Verzeichnis server/default/conf/ liegende Log4J Konfigurationsdatei jboss-log4j.xml neu konfigurieren und laden. Somit lässt sich auch während des Betriebs z.B. das Loglevel anpassen. Aber dazu ein ander mal mehr.

Man kann den Funktionsumfang für die Formatierungsmöglichkeiten soweit abspecken, dass nur noch das nötigste für den Benutzer möglich ist:

Wer den Editor live ausprobieren möchte kann dies auf der RichFaces Live Demo direkt tun. Die einfachste Variante den Editor einzubinden und zu verwenden ist:

<rich:editor value="#{myBean.editorContent}"/>

Die Editor Komponente selbst basiert auf den sehr bekannten TinyMCE JavaScript WYSIWYG Editor und bisher musste man, wenn man einen solchen Rich Editor wollte, diesen manuell in sein Projekt einbinden.

Ich werde den Editor die Tage mal ausprobieren und dann wird man sehen ob er sich so einfach einbinden und verwenden lässt wie es bei den vielen anderen RichFaces Komponenten war.

Neben dem Editor ist noch eine weitere Ajax Komponente hinzugekommen: Ajax Queue. Mit dieser ist es möglich direkt hintereinander abgesetzte Ajax Request so zu managen, dass der zweite Ajax Request erst abgesetzt wird wenn der erste beendet wurde. Somit kann man parallele Ajax Requests verhindern.

Wer bisher noch nichts von den RichFaces bzw. das dazugehörige Ajax4Jsf gehört hat der sollte sich auf der Live Demo Seite die vielen Beispiele mal ansehen. Neben den fertigen Ajax Komponenten wie z.b. die DataTable, Inplace Edit, Tree oder File Upload (um nur einige zu nennen) ist vor allem der Ajax4Jsf Teil sehr interessant. Mit diesem lassen mit einfachen Mitteln bzw. Komponenten normale JSF Seiten “Ajaxifizieren” (a4j:support), es lassen sich JavaScript Methoden dynamisch erzeugen (a4j:jsfunction) die mit JSF Managed Beans reden oder Teile der JSF Seite neu Rendern oder man kann den Server mit Hilfe von Ajax Anfragen um z.B. einen Status abzufragen (a4j:poll).
Persönlich finde ich genau diesen Ajax4Jsf Teil und die gesamte Einfachheit der Verwendung der RichFaces Komponenten den Grund warum ich die JBoss RichFaces sehr empfehlen kann.

Noch ein letzter Tipp: Wer mit den RichFaces arbeitet sollte sich auf alle Fälle die JBoss Tools in Eclipse installieren um die direkte RichFaces Unterstützung im JSF Editor zu erhalten. Neben Autocomplete bei den Komponenten, dem Rich Editor für JSF oder xhtml Seiten erkennt er auch Expressions und kann auf die Methoden und Beans referenzieren.

Viel Spass beim ausprobieren!

Grundsätzlich wird von JBoss darauf verwiesen, dass eine einzige JBoss Server Installation mehrere Instanzen verwalten kann. Das geschieht durch die verschiedenen Server Konfigurationsverzeichnisse:

• $JBOSS_HOME
• server
• default
• node1
• node2
• nodeX

In meinem speziellem Fall war es dennoch nicht anders zu lösen als eine komplette neue JBoss Installation in einem anderen Verzeichnis. Das Ergebnis war natürlich, dass die beiden JBoss AS Installationen Portkonflikte anzeigten und der zuletzt gestartet JBoss AS nur Exceptions ausspuckte.

Es bestehen für dieses Problem zwei Lösungen: Entweder man vergibt jedem JBoss eine eigene IP Adresse (./run.sh -b 192.168.1.2) und somit sind die Port Bindings auch voneinander getrennt oder man vergibt jeder JBoss AS Instanz unterschiedliche Ports.
In meinem Fall war die zweite Lösung, verschieden Ports vergeben, die einzige Möglichkeit die zwei JBoss AS Instanzen auf der gleichen Maschine voneinander zu trennen.

Verschiedene Ports zu vergeben gestaltet sich im JBoss AS recht einfach. Man kann natürlich alle Ports in jeder einzelnen Konfigurationsdatei manuell von Hand ändern und hoffen, dass man alles richtig gemacht hat.
Viel empfehlenswerter ist allerdings die Verwendung des Service Binding Manager. Mit diesem ist es möglich weitreichende Änderungen an den einzelnen Konfigurationsdateien Ports zu verändern. In der Default Konfiguration des JBoss AS ist dieser Service Binding Manager nicht aktiv (in den Kommentar eingeschlossen) und es werden die vorgegebenen Ports verwendet.

Um den Service Binding Manager zu verwenden muss die entsprechende Stelle in der jboss-service.xml auskommentiert werden. Die jboss-service.xml befindet sich im conf Verzeichnisses unterhalb eines Server Konfigurationsverzeichnisses. Für den Default Server somit unter jboss-4.2.2.GA\server\default\conf.

Darin die folgenden Zeilen auskommentieren.

  
    ports-01
    ${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml
    org.jboss.services.binding.XMLServicesStoreFactory

In der spample-bindings.xml Datei sind sämtliche in JBoss konfigurierbare Ports aufgelistet und können nach belieben verändert werden bzw. dieses spample-bindings.xml kann schon verwendet werden um den JBoss AS auf komplett anderen Ports laufen zu lassen.
So wird z.B. auch der HTTP Port in dieser Beispielkonfiguration auf 8180 (default ist 8080) konfiguriert:

  
    ...
    
    
      
      
    
    ...
  

Für eine genauere Dokumentation der XML Datei und der einzelnen XML Elemente sei auf den Server Configuration Guide Kapitel 10.2 verwiesen.

Insgesamt eine schöne und saubere Möglichkeit Port Bindings zu konfigurieren und wiederzuverwenden.
Für weiterführende Dokumentation rund um die Konfiguration der Ports und einzelner JBoss AS Instanzen empfehle ich das JBoss Wiki:

• Configuring Multiple JBoss Instances On One Machine
• Setting up multiple instances of JBoss on the same machine – Binding Manager
• Service Binding Manager in JBoss Application Server 5

21:10:03,406 INFO  [STDOUT] Hibernate:
    insert
    into
        REGISTERED_USER
        (version, NAME, USER_TYPE, CONF_FK, id)
    values
        (?, ?, ?, ?, ?)

Das für den Entwickler eigentlich interessante, nämlich die Parameter in der values Zeile, wird wegen der Verwendung von Prepared Statements nur durch Fragezeichen ausgegeben.

Die allgemein gültige Lösung dafür ist das Log Level für Hibernate Kategorie org.hibernate.type auf TRACE zu setzen. In einer log4j.properties Datei reichen die folgenden beiden Angaben um die SQL Statements sowie deren Paramter im Log auszugeben:

Arbeitet man mit der log4j.xml Konfigurationsdatei muss man die Kategorie wie folgt konfigurieren:

<category name="org.hibernate.type">
  <priority value="TRACE"/>
  <appender-ref ref="CONSOLE"/>
</category>

Die Kategorie org.hibernate.SQL muss man nicht unbedingt konfigurieren wenn man in der Hibernate Konfiguration, die bei der Nutzung von JPA in der Datei persistence.xml zu finden ist, den Parameter hibernate.show_sql auf true setzt:

<property name="hibernate.show_sql" value="true"/>

Überschreibt man die in der log4j Konfiguration die Kategorie org.hibernate.SQL hat diese Einstellung in der persistence.xml keine Wirkung.

Arbeitet man mit JBoss Seam unter dem JBoss AS verhält es sich grundsätzlich genauso wie oben beschrieben:

• Konfiguration des show_sql Flags auf den Wert true in der persistence.xml
• Die Log4J Konfiguration für Hibernate erweitern: Im JBoss AS Installationsordner unter <JBossAs>\server\default\conf die Datei jboss-log4j.xml editieren und die Hibernate Kategorie org.hibernate.type wie oben beschrieben hinzufügen

Da hier das Log Level auf TRACE gesetzt wird muss man das Level für den Appender auch auf TRACE setzen um den entsprechenden Effekt zu erhalten. Es ist nicht unbedingt ratsam den Default Appender, hier CONSOLE auf TRACE zu setzen weil sonst alle für diesen Appender konfigurierten Kategorien viel und laut sprechen.
Es bietet sich stattdessen an einen eigenen Hibernate Appender zu erstellen und nur diesen auf TRACE zu setzen. Bei mir sieht die jboss-log4j.xml für Hibernate wie folgt aus. Zuerst der Hibernate Appender:

<appender name="HIBERNATE" class="org.apache.log4j.ConsoleAppender">
  <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
  <param name="Target" value="System.out"/>
  <param name="Threshold" value="TRACE"/>

  <layout class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
  </layout>
</appender>

Die Hibernate org.hibernate.type Kategorie Konfiguration:

<category name="org.hibernate.type">
  <priority value="TRACE"/>
  <appender-ref ref="HIBERNATE"/>
</category>

Eigentlich ziemlich simpel.

Führt man nun das am Anfang beschriebene SQL Statement nochmal aus ist auf der Konsole folgendes zu sehen:

21:30:11,756 INFO  [STDOUT] Hibernate:
    insert
    into
        REGISTERED_USER
        (version, NAME, USER_TYPE, CONF_FK, id)
    values
        (?, ?, ?, ?, ?)
21:30:11,756 TRACE [IntegerType] binding '0' to parameter: 1
21:30:11,756 TRACE [StringType] binding 'Markus' to parameter: 2
21:30:11,756 DEBUG [EnumType] Binding 'ADMIN' to parameter: 3
21:30:11,756 TRACE [LongType] binding '41' to parameter: 4
21:30:11,756 TRACE [LongType] binding '41' to parameter: 5

Und kaum hat man diese wenigen Konfigurationselemente hinzugefügt spricht Hibernate schon eine viel deutlichere und schönere Sprache für uns.

Um JMX zu nutzen werden sogenannte MBeans (Managed Beans) erstellt welche über einen Adapter, wie zum Beispiel einen HTTP Adapter, über den Web Browser zugänglich gemacht werden. Mit Java 5 kommt auch noch die Möglichkeit auf die JConsole zu verwenden um auf MBeans zuzugreifen. Mehr zu den Grundlagen der Java Management Extension auch in der online Ausgabe Java ist auch eine Insel – Kapitel 23.

Der JBoss AS (Application Server) steuert seine Konfigurationen über einen eigenen JMX Bus und bietet dazu eine Menge an MBeans an – siehe dazu auch aus dem JBoss AS Guide – Kapitel 2 – The JBoss JMX Microkernel. Weil die JMX Unterstützung eine Kernkomponente für den JBoss ist bietet er einfache Möglichkeiten an diese Infrastruktur für die eigenen Zwecke zu verwenden. Wie man diese am einfachsten verwenden und selbst eine JMX MBean schreiben kann soll im folgenden gezeigt werden.

Dieser Artikel ist in die folgenden Abschnitten unterteilt:

• Verschiedene Arten der JBoss MBean Services
• JBoss Service POJO
• JMX Konsole – Management Interface mit XML beschreiben

Möchte man eine JMX Bean für die eigene Anwendung, welche auf dem JBoss AS (Application Server) läuft, schreiben so bietet JBoss mehrere Möglichkeiten an. Folgende drei Möglichkeiten bestehen eine MBean für die JMX Konsole zu implementieren und zu registrieren:

• JBoss Standard MBean
• JBoss XMBean
• JBoss Servie POJO

Obwohl ich nur auf die dritte und letzte Möglichkeit eingehen möchte, werden vorab die beiden anderen Varianten kurz erwähnt, so dass man diese einordnen kann.

Für die erste Variante implementiert man einen JBoss MBean Service (auch Standard MBean genannt). Dazu erstellt man ein Interface welches sich von org.jboss.system.ServiceMBean sowie eine Klasse die dieses Interfaces implementiert. Diese MBean Service Klasse ist selbst von der Klasse org.jboss.system.ServiceMBeanSupport abgeleitet ist. Diese Klasse wird nun in der Datei jboss-service.xml als MBean konfiguriert und so dem JBoss AS bekannt gemacht.
Ein kleines “Hello World Service” Tutorial für das Erstellen eines solchen JBoss MBean Services findet sich im JBoss Wiki.

Die zweite Variante basiert auf der eben vorgestellten, nur dass die MBean über das JBoss XMBean Framework seine Metadaten beschreibt. An dieser Stelle kommt die Möglichkeit einfache POJOs als MBeans zu verwenden ins Spiel und es ist nicht mehr notwendig das oben beschriebene Interface ServiceMBean zu implementieren oder andere Regeln in der MBean Klasse einzuhalten. Allerdings wird für diese sogenannte XMBean Deployment Descriptor in Form eines XML Dokuments benötigt. Aus diesem Grund heißt diese MBean XMBean.
In diesem Deplyoment Descriptor können sämtliche Attribute, Methoden und deren Parameter beschrieben werden. Ein weiter Vorteil war die Möglichkeit Interceptor-Methoden zu implementieren. Diese konnte man zum Beispiel für Sicherheitsüberprüfungen bei Methodenaufrufe verwenden. Eine schöne ausführliche Beschreibung der XMBean findet sich auf dem Blog von organig thoughts.

Die hier eben kurz erwähnten Wege eine JBoss MBean bzw. XMBean (beides sind JMX MBean) zu erstellen können auch noch einmal in der offiziellen JBoss Server Configuration Guide im Kapitel 3.4.3 mit dem Titel “Writing JBoss MBean Services” nachgelesen werden.

Die dritte Variante ist die in diesem Artikel eigentlich fokussierte Variante mit dem Namen JBoss Service POJOs.

Die einfachste Variante eine JBoss MBean für die JMX Konsole zu erstellen ergibt sich durch die JBoss eigene @org.jboss.annotation.ejb.Service Annotation. Diese Annotation @Service definiert im JBoss einen Service der als Singleton, also nur mit einer Instanz (Singleton), verfügbar ist. So ergibt sich der erste Schritt daraus, einen solchen Service zu erstellen.

import org.jboss.annotation.ejb.Service;

@Service(objectName="MyApplication:service=MyService")
public class MyServiceMBean {

}

Noch einmal: die Besonderheit an dieser Service Bean besteht darin, dass auf dem Server nur eine Instanz davon besteht. Im Gegensatz zu EJB Services ist ein MBean Service nicht gepoolt, behält seinen Status (stateful) und hat application-scope. Letztlich ist dies aber eine normale Session Bean, von der lediglich nur eine Instanz besteht. Man arbeitet somit in dem Context der Anwendung und kann auf alle konfigurierten Resourcen, wie z.b. den EntityManager oder andere EJBs, zugreifen.

Um diese Service EJB nun noch JMX fähig zu machen und sie an einem MBean Server anmelden zu können, muss nun noch ein Management Interface erstellt und der Service Bean durch die @org.jboss.annotation.ejb.Management Annotation bekannt gemacht werden.

Hier das Management Interface, welche die Getter und Setter für das Attribut “lastWrittenText” sowie die Service-Methode printOut() deklariert, die später über die JMX Konsole aufgerufen werden können.

public interface MyManagementInterface {

  public String getLastWrittenText();
  public void setLastWrittenText(String lastWrittenText);

  void printOut(String text);
}

Die erstellte Service MBean “MyServiceMBean” muss dieses Interface nun noch implementieren und zudem das gleiche Interface durch die @Management Annotation bekannt machen. Erst durch diese @Management Annotation wird der JBoss aus den beschriebenen Attributen und Methoden eine Service MBean erstellen und registrieren. Im folgenden der vollständige Source Code für den POJO Service “MyServiceMBean“:

import org.jboss.annotation.ejb.Management;
import org.jboss.annotation.ejb.Service;

@Service(objectName="MyApplication:service=MyService")
@Management(MyManagementInterface.class)
public class MyServiceMBean implements MyManagementInterface {

  private String lastWrittenText;

  public void printOut(String text) {
    System.out.println("Given text: " + text);
    lastWrittenText = text;
  }

  public String getLastWrittenText() {
    return lastWrittenText;
  }

  public void setLastWrittenText(String lastWrittenText) {
    this.lastWrittenText = lastWrittenText;
  }
}

In dem Code ist zu sehen, das bei der @Service Annotation noch ein Objektname zu finden ist. Dieser dort definierte Name erscheint nach dem Starten des JBoss und dem erfolgreichem deployen der Anwendung in der JMX Konsole (Aufzurufen durch http://localhost:8080/jmx-console/). Im folgenden Screenshot findet man die definierten Namen wieder:

Selektiert man diesen Service gelangt man in die Service View, in der man alle Attribute und Methoden des Services sehen und aufrufen kann. In diesem Beispiel soll die Methode printOut(String) aufgerufen werden:

Nach der Eingabe des Methodenparameters “test string” und dem anschließenden Klicken des Buttons “invoke” erscheint auch, wie erwartet, der übergebene Text in der Server Konsole:

Leider hat man durch die Verwendung der Annotationen keine Möglichkeit die Service Bean, Attribute, Methoden oder Paramter zu beschreiben, wie es bei der ursprünglichen XMBean Variante noch als großer Vorteil angepriesen wurde.
Die gute Nachricht ist, dass auch hier eine Möglichkeit besteht diese Beschreibungen zu liefern. Der Nachteil an der Sache ist, man muss wieder auf eine XML Beschreibung zurückgreifen. Und zwar kommt wieder der XML Deployment Descriptor der XMBeans ins Spiel. Man kann genau diesen in der @Service Annotation angeben.

@Service(objectName="MyApplication:service=MyService",
		 xmbean="resource:META-INF/myService-xmbean.xml")
public class MyServiceMBean  implements MyManagementInterface {
  ...
}

Wichtig ist, dass die @Management Annotation entfernt werden muss weil nun wieder der XMBeans Deployment Descriptor die Beschreibung der MBean übernimmt. In diesem Beispiel heißt der Deployment Descriptor myService-xmbean.xml und liegt im META-INF Ordner, direkt neben der persistence.xml Datei. Wenn die Datei nicht gefunden wird schmeißt der JBoss AS während des Startens Exceptions, so dass der Fehler schnell bemerkt wird.

Der XMBeans Deployment Descriptor myService-xmbean.xml sieht für die oben gelistete POJO Service Klasse wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mbean PUBLIC "-//JBoss//DTD JBOSS XMBEAN 1.0//EN"
  "http://www.jboss.org/j2ee/dtd/jboss_xmbean_1_0.dtd">


  javathreads.de - MyService MBean Beschreibung

  de.webthreads.tippit.mgmt.MyServiceMBean

  
  
    Der zuletzt ausgegebene Text wird hier gehalten.
    LastWrittenText
    java.lang.String
  

  
  
    Methode um einen Text auf der Konsole auszugeben.
    printOut

      Der Text der ausgegeben werden soll.
      text
      java.lang.String
    
    void
  

In der XML Datei sind die Beschreibungen für das Attribut sowie der Methode zu sehen. Die DTD des mbean Elements sieht wie folgt aus:

Schaut man sich jetzt die JMX Konsole an sind die Beschreibungen nun auch vorhanden, wie man im folgenden Screenshot sehen kann:

Ich habe in diesem Screenshot mal die Abhängkigkeit zur XMBean hervorgehoben. Vergleicht man diese Zeile mit dem Screenshot der JMX MBean View der MBean, die mit der @Management erstellt wurde, so sieht man dort die Zeile: MBean Java Class: de.javathreads.jbosstest.mgmt.MyManagementInterface

Auch so kann man also erkennen welcher Weg gegangen wurde um eine MBean für die JMX Konsole zu erstellen.

Insgesamt war das Erstellen einer solchen Service MBean im JBoss so einfach, dass ich es hier kurz dokumentieren musste =). Der Weg dahin hat doch etwas länger gedauert aber dadurch bin ich über einige interessante Seiten gestolpert, wie zum Beispiel das JBoss Wiki – JMX FAQ oder das wirklich gute Tutorial von JBoss Trailblazer. Nach dem lesen und googeln habe ich es ausprobiert und es hat tatsächlich (fast) auf Anhieb funktioniert.
Und jetzt während ich diesen Artikel fast zu Ende geschrieben habe entdecke ich noch eine Blitzanleitung auf dem Blog von Christian Ullenboom (Author von Java ist auch eine Insel) mit einer Schnelleinführung..

Und gerade weil das Erstellen eines solchen JMX MBean Service eigentlich so einfach ist sollten diese Erkenntnisse hier festgehalten werden.

Für den JSR 301 bestehen schon mehrere Implementierungen vorhanden, wie zum Beispiel die OpenPortal JSF Portlet Bridge oder die MyFaces Portlet Bridge.
Nun hat auch JBoss eine eigene Portlet Bridge Implementierung veröffentlicht, die es ermöglichen soll einfach beliebige Web Frameworks in Portlets einzubinden. In der ersten 1.0.0 Beta Version werden JBoss Seam und JBoss RichFaces direkt unterstützt.

In einer Demo ist das Seam Beispiel “Hotel Booking” in einem JBoss Portal zu sehen.

In einem weiteren Demo kann man die RichFaces Demo Seite komplett in einem Portlet abrufen und ausführen. Das amüsante hier ist, dass man an die offizielle RichFaces Demo Seite nur noch über ein Login austesten darf während über die Portlet Bridge Demo Seite die RichFaces Demos noch öffentlich zugänglich sind. Aber generell finde ich es schade, dass man sich für die RichFaces Demo Seite erst anmelden muss..

Für die Dokumentation hat JBoss wieder ein eigenes Portlet Bridge Wiki angelegt. Dort sind schon einige Seiten erstellt worden unter anderem ist auch die Seite “Getting Started” zu finden. Ein Beispiel wie die Konfiguration in der faces-config.xml, portlet.xml und web.xml für die Einbindung aussieht ist auch im Wiki auf der Seite WikiJBPBConfig zu sehen.
Für Fragen aller Art steht auch noch ein eigenes Forum zur Verfügung.

(via JBoss Portal Blog)