lifecycle = WebBeansContext.getInstance().getService(ContainerLifecycle.class);

durch

lifecycle = WebBeansContext.currentInstance().getService(ContainerLifecycle.class);

Und der Einsatz von CDI mit OpenWebBeans in einer Java SE Umgebung steht nix mehr im Weg.

Zur Vollständigkeit anbei die Maven pom.xml:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

	<modelVersion>4.0.0</modelVersion>
	<groupId>com.haddouti.maven</groupId>
	<artifactId>cdi-test</artifactId>
	<packaging>jar</packaging>
	<version>0.0.1-SNAPSHOT</version>
	<name>cdi-test</name>

	<url>http://www.haddouti.com</url>

	<dependencies>

		<!-- CDI Impl: Apache OpenWebBeans -->
		<dependency>
			<groupId>org.apache.openwebbeans</groupId>
			<artifactId>openwebbeans-impl</artifactId>
			<version>1.1.2</version>
		</dependency>

        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-el_2.2_spec</artifactId>
            <version>1.0.2</version>
        </dependency>

        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-interceptor_1.1_spec</artifactId>
            <version>1.0</version>
            <optional>true</optional>
        </dependency>

		<!-- JSR-299 -->
        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-jcdi_1.0_spec</artifactId>
            <version>1.0</version>
            <optional>true</optional>
        </dependency>

		<!-- JSR-330 -->
        <dependency>
            <groupId>org.apache.geronimo.specs</groupId>
            <artifactId>geronimo-atinject_1.0_spec</artifactId>
            <version>1.0</version>
            <optional>true</optional>
        </dependency>

        <dependency>
            <groupId>org.apache.openwebbeans</groupId>
            <artifactId>openwebbeans-spi</artifactId>
            <version>1.1.2</version>
        </dependency>

	</dependencies>
</project>

[1] http://www.jcp.org/en/jsr/summary?id=299
[2] http://blog.namics.com/2011/01/cdi-leichtgewic.html
[3] http://matthiaswessendorf.wordpress.com/2010/01/19/dependency-injection-the-jsr-330-way/
[4] http://www.adam-bien.com/roller/abien/entry/simplest_possible_ejb_3_15
[5] http://seamframework.org/Weld
[6] http://openwebbeans.apache.org/owb/index.html
[7] http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/environments.html#d0e5333
[8] http://svn.apache.org/repos/asf/openwebbeans/trunk/samples/standalone-sample/src/main/java/org/apache/webbeans/se/sample/Boot.java

var http = require('http'),
	url = require('url');

var results = ["status=OK&desc=Alles paletti&url=http://www.heise.de/",
			   "status=NOK&desc=Oh, problem&url="];

var httpServer = http.createServer();

httpServer.on('request', function(request, response) {
	// Parse the entire URI to get just the query
	var query = url.parse(request.url, true).query;
	// parse the query parameters
	var param1 	= query['p1'];
	var param2	= query['p2'];
	var param3	= query['p3'];

	// Do something with the parameters to generate the response.....

	// return random response
	response.writeHead(200, {'Content-Type': 'text/plain'});
	var rnd = Math.floor(Math.random() * results.length)
	response.end(results[rnd]);
});

httpServer.listen(1337, '127.0.0.1');

console.log('- Server running at http://127.0.0.1:1337/');

Wie man sehen kann, wird in wenigen Zeilen JavaScript ein HTTP-Server geschrieben, der auf den “request”-Event horcht. Bei jedem Request werden die Parameter ermittelt und die Response generiert.
Nodejs bietet verschiedene Events an, für die ein Callback-Funktion registriert werden kann.
Beim HTTP-Server sind das z.B.: request, connection, close. Weitere Details sind in der Docu zu finden.

Links:

• Nodejs API: http://nodejs.org/docs/v0.4.7/api/all.html

Mit Eclipse mal fix ein dynamisches Webprojekt erstellt. Drauf geachtet, dass REST (JAX-RS) ausgewählt wird. Glassfish ist schon vom letzten Projekt in Eclipse integriert.
Während der Projekterstellung bietet der Wizard u.a. die Konfiguration für REST an. Da kann u.a. das URL matching pattern eingeben werden (default: /rest/*)

Als erstes erstellen wir eine REST-Klasse die alle MBeans auflisten.

import java.lang.management.ManagementFactory;
import java.util.Set;

import javax.management.MBeanServer;
import javax.management.ObjectInstance;
import javax.ws.rs.GET;
import javax.ws.rs.Path;

/**
 * REST JMX Monitor
 *
 * @author haf
 *
 */
@Path("rjm")
public class RestJmxMonitor {

	@GET
	@Path("all")
	public String getAllMBeans() {

		MBeanServer mbServer = ManagementFactory.getPlatformMBeanServer();
		Set<ObjectInstance> mbeans = mbServer.queryMBeans(null, null);
		StringBuilder sb = new StringBuilder();
		sb.append("MBeans:<br />");
		for(ObjectInstance oi: mbeans) {
			sb.append(oi.getObjectName());
//			sb.append(" - ");
//			sb.append(oi.getClassName());
			sb.append("<br />");
		}

		return sb.toString();
	}
}

Glassfish starten. URL http://localhost:8080/JmxMonitor/rest/rjm/all aufrufen und die ObjectNames der MBeans begutachten.
Vielleicht noch ein paar Worte zu den ObjectNames. Diese identifizieren ein MBean eindeutig und hat folgendes Format:
Domain-name:key1=value1[,key2=value2,...keyX=valueX]
Weitere Details unter ObjectName.

Um z.B. die Attribute für ein bestimmten MBean anzuzeigen, kann man folgende Methode anbieten:

@GET
	@Path("mb/{objectName : .+}")
	public String getMBean(@PathParam("objectName") String objectName) {

		MBeanServer mbServer = ManagementFactory.getPlatformMBeanServer();
		StringBuilder sb = new StringBuilder();
		try {
			Set<ObjectInstance> mbeans = mbServer.queryMBeans(new ObjectName(objectName), null);
			sb.append("MBeans:<br />");
			for(ObjectInstance oi: mbeans) {
				sb.append(oi.getObjectName());
				sb.append("<br />");
				final MBeanAttributeInfo[] attributes = mbServer.getMBeanInfo(oi.getObjectName()).getAttributes();
				sb.append("Attributes:<br />");
                for (final MBeanAttributeInfo attribute : attributes) {
                	sb.append("- ");
                	sb.append(attribute.getType());
                	sb.append(" ");
                	sb.append(attribute.getName());
                	sb.append("=");

                	Object value;
					try {
						value = mbServer.getAttribute(oi.getObjectName(), attribute.getName());
						sb.append(value);
					} catch (AttributeNotFoundException e) {
						e.printStackTrace();
					}
                	sb.append("<br />");
                }
                sb.append("<br />");
			}

		} catch (MalformedObjectNameException e) {
			e.printStackTrace();
		} catch (NullPointerException e) {
			e.printStackTrace();
		} catch (IntrospectionException e) {
			e.printStackTrace();
		} catch (InstanceNotFoundException e) {
			e.printStackTrace();
		} catch (ReflectionException e) {
			e.printStackTrace();
		} catch (MBeanException e) {
			e.printStackTrace();
		}

		return sb.toString();
	}

Teste man dies z.B. mit http://localhost:8080/JmxMonitor/rest/rjm/mb/com.sun.appserv:type=Loader,path=/,host=server erhält man die Attribute.

Hier sei angemerkt, dass der PathParam mit einem Regex angegeben wird, da der ObjectName das ungültige Zeichen / beinhalten kann. Falls man kein Regex verwenden möchte, kann ein @QueryParam verwendet werden.

Wie man sehen kann, kann man recht fix eine rudimentäre Implementierung eines JMX Monitor mit REST realisieren.
Das ganze ist natürlich ausbaubar: bessere Suche (Domain, Query), andere Ausgabeformate, setzen von Werten etc.

Nächster Teil folgt.

Links:
Adam Bien: http://adam-bien.com/roller/abien/
JSR 311: JAX-RS: The JavaTM API for RESTful Web Services: http://jcp.org/en/jsr/summary?id=311
JSR 339: JAX-RS 2.0: The Java API for RESTful Web Services: http://jcp.org/en/jsr/summary?id=339
Glassfish: http://glassfish.java.net/

• SYSCS_UTIL.SYSCS_EXPORT_TABLE: Zum exportieren einer kompletten Tabelle
• SYSCS_UTIL.SYSCS_EXPORT_QUERY: Exportiert die Daten, die dem mitgegebenen SELECT entsprechen
• SYSCS_UTIL.SYSCS_BACKUP_DATABASE: Kompletter Backup der DB.

Die Export-Procedures liefern eine CSV-Datei, wobei man die Trennzeichen definieren kann.
Beim Backup-Procedure wird die ganze Ordnerstruktur in einen gewünschten Ordner kopiert.

Zum Exportieren einer ganzen Tabelle sieht die Signatur der Procedure wie folgt aus:

SYSCS_UTIL.SYSCS_EXPORT_TABLE (
	IN SCHEMANAME  VARCHAR(128),
	IN TABLENAME VARCHAR(128),
	IN FILENAME VARCHAR(32672),
	IN COLUMNDELIMITER CHAR(1),
	IN CHARACTERDELIMITER CHAR(1),
	IN CODESET VARCHAR(128)
)

…für eine definierte Datenmenge

SYSCS_UTIL.SYSCS_EXPORT_QUERY(
	IN SELECTSTATEMENT VARCHAR(32672),
	IN FILENAME VARCHAR(32672),
	IN COLUMNDELIMITER CHAR(1),
	IN CHARACTERDELIMITER CHAR(1),
	IN CODESET VARCHAR(128)
)

Beispielhaft (mit JPA)

public void exportTable()
{
	final Object[] paras = new Object[6];
	paras[0] = „DB-SCHEMA“;
	paras[1] = „TABLE-NAME“;
	paras[2] = „EXPORT-FILE-PATH.csv“;
	// Column delimiter
	paras[3] = ';';
	// character delimiter
	paras[4] = '|';
	// Codeset
	paras[5] = „UTF-8“;

	callProcedure(„{call SYSCS_UTIL.SYSCS_EXPORT_TABLE (?,?,?,?,?,?)}“, paras);
}

public void exportData()
{
	final Object[] paras = new Object[5];
	paras[0] = „SELECT * FROM TABLE-NAME WHERE id IN (1, 2, 99) AND ...“;
	paras[1] = „EXPORT-FILE-PATH.csv“;
	// Column delimiter
	paras[2] = ';';
	// character delimiter
	paras[3] = '|';
	// Codeset
	paras[4] = „UTF-8“;

	callProcedure(„{call SYSCS_UTIL.SYSCS_EXPORT_TABLE (?,?,?,?,?,?)}“, paras);
}

public void callProcedure(final String sql, final Object... parameters)
{
	final Query query = entityManager.createNativeQuery(sql);
	int counter = 1;
	for(Object o: parameters)
	{
		query.setParameter(i++, o);
	}

}

Links:

• Derby DB: http://db.apache.org/derby/
• Derby Referenz Guide – Export Data: http://db.apache.org/derby/docs/10.7/ref/ref-single.html#rrefexportselectionproc
• Derby Referenz Guide – Export Table: http://db.apache.org/derby/docs/10.7/ref/ref-single.html#rrefexportproc
• Derby Referenz Guide – Backup: http://db.apache.org/derby/docs/10.7/ref/ref-single.html#rrefbackupdbproc

Im Spring-Kontext gilt folgendes: In JPA braucht man pro EntityManagerFactory eine Datasource. Der EMF ist einen TransactionManager zugeordnet.

Man könnte alle Datasource, EMF, TX-Manager und PUs in Spring konfigurieren. Man hat jedoch ein Problem, wenn man n verschiedene Datasourcen hat, die zur Laufzeit ausgewählt werden müssen.

• Die Konfiguration ist umfangreich und unübersichtlich
  • Pro Datasource ist ein Persistence-Unit notwendig, denn für die Ermittlung des richtigen EntityManager kann @PersistenceContext(unitName = “PU_NAME”) verwendet werden
  • Pro Datasource einen EntityManagerFactory mit der Verknüpfung zur PersistenceUnit
  • Pro EntityManagerFactory einen TransactionManager, ggf. mit Qualifier.
• Die Wartung ist entsprechend nicht optimal. Pro neue Datasource müssen 3 Stellen angepasst werden
• Das Transaction-Handling wird kompliziert. @Transactional muss nun immer den richtigen TransactionManager nutzen. Die Entscheidung soll natürlich zur Laufzeit passieren. @Transactional(“TX_MANAGER_NAME”) reicht nicht aus, da es eine statische Kopplung verursacht.

Eine andere Lösungsvariante wäre, statt einen EntityManager durch @PersitenceContext eher direkt den EntityManagerFactory durch @PersistenceUnit zu bekommen. Hier modifiziert man die EntityManager-Erstellung soweit, dass man den EntityManager mit der gewünschten Datasource bekommt. Falls sich bei den Datasourcen nur die User unterscheiden und Eclipselink verwendet wird, siehe u.a. [1].

Perfekt wäre jedoch eine Lösung, in der nur EntityManagerFactory, ein TransactionManager und ein PersistenceUnit verwendet wird. Zur Laufzeit soll dann der vorhandene EntityManagerFactory für die gewünschte Datasource einen EntityManager erstellen.

Das funktioniert. Der EntityManagerFactory erwartet eine Referenz auf die DataSource. Hier könnte man eine eigene Implementierung dieses Interface anbieten, welches die Unterscheidung bzgl. der verschiedenen Datasourcen durchführt. DataSource.getConnection() muss dann abhängig von fest definierten Eigenschaften die Connection von der richtigen Datasource zurückgeben. Um die Eigenschaften in der eigenen DataSource-Implementierung abzufragen, ist die Nutzung von ThreadLocal bzw. InheritableThreadLocal möglich.

Eine Spring-spezifische Lösung die in diese Richtung geht, ist mittels AbstractRoutingDatasource möglich [2]. Hier muss die abstrakte Methode determineCurrentLookupKey() implementiert werden. In dieser Methode muss die Logik verpackt werden, damit anhand des resultierenden Keys die richtige Datasource verwendet werden kann. Das Mapping zwischen Key und Datasource wird in AbstractRoutingDatasources#targetDataSources gehalten. Wird kein Key zurückgeliefert, wird die vorher definierte Standard-Datasource verwendet.

Eine Beispiel-Implementierung, welches mit Spring 3.x und jeweils mit Eclipselink und Hibernate funktioniert, sieht wie folgt aus:

Die relevante Spring-Konfiguration:

<bean id="baseDataSource" abstract="true">
<property name="driverClassName" value="${db.driverClassName}"/>
<property name="url" value="${db.url}"/>
</bean>

<bean id="dataSource1" parent="baseDataSource">
<property name="user" value="${db.1.user}"/>
<property name="password" value="${db.1.pw}"/>
</bean>
<bean id="dataSource2" parent="baseDataSource">
<property name="user" value="${db.2.user}"/>
<property name="password" value="${db.2.pw}"/>
</bean>
<bean id="dataSource3" parent="baseDataSource">
<property name="user" value="${db.3.user}"/>
<property name="password" value="${db.3.pw}"/>
</bean>

<bean id="dynamicDatasource" class="info.center-of.spring.jpa.DynamicDataSourceRouting">
<property name="targetDataSources">
<entry key="${db.1.user}" value-ref="dataSource1"/>
<entry key="${db.2.user}" value-ref="dataSource2"/>
<entry key="${db.3.user}" value-ref="dataSource3"/>
</property>
<property name="defaultTargetDataSource" ref="dataSource1"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalEntityManagerFactoryBean">
<property name="datasource" ref="dynamicDatasource" />
<property name="jpaVendorAdapter">
<!-- Fuer Hibernate -->
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" p:showSql="true" generateDdl="true" />
<!-- Fuer Eclipselink
<bean class="org.springframework.orm.jpa.vendor.EclipselinkJpaVendorAdapter" p:showSql="true" generateDdl="true" />
-->
</property>
</bean>

<bean class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="entityManagerFactory" />
</bean>

<tx:annotation-driven />

Die Klasse DynamicDataSourceRouting überschreibt die Methode zur Ermittlung des Keys. In unserem Fall ist dies immer der aktuelle/gewünschte DB-User:

import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;

public class CustomerRoutingDataSource extends AbstractRoutingDataSource {

@Override
protected Object determineCurrentLookupKey() {
return DBUserContextHolder.getDBUser();
}
}

DBUserContextHolder ist eine Klasse mit einer ThreadLocal-Variable, die in dem aktuellen Thread den DB-User hält

public class DBUserContextHolder {

private static final InheritableThreadLocal<String> contextHolder = new InheritableThreadLocal<String>();

public static void setDBUser(final String dbUser) {
contextHolder.set(dbUser);
}

public static String getDBUser() {
return (String) contextHolder.get();
}

public static void clear() {
contextHolder.remove();
}
}

Bevor der EntityManager nun erstellt wird, muss

DBUserContextHolder.setDBUser("dbUser1");

aufgerufen werden.

Mit dieser Lösung hat man “nur” eine enge Kopplung mit Spring. Die Lösung funktioniert mit verschiedenen ORMs.

[1]: Wikibook JPA: Provide each application user with a database user id

[2]: Spring Blog: Dynamic DataSource Routing

<system.diagnostics>
  <switches>
     <add name="XmlSerialization.Compilation" value="true" />
  </switches>
</system.diagnostics>

Nun kann man entweder die .CS-Datei oder die generierte DLL-Datei in das eigene Projekt integrieren. Dann ist die direkte Nutzung von XmlSerializer nicht mehr notwendig.

Mit dieser Lösung wird zur Laufzeit die csc.exe nicht mehr benötigt und entsprechend die Performance verbessert.

Links:
- XmlSerializer: http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx

Technologie
In der Lösung wird nur Spring AOP und Ehcache direkt verwendet. Bei der AOP Implementierung wird nicht AspectJ verwendet um die Anzahl der abhängigen Bibliotheken gering zu halten. Dies ist auch möglich, da die benötigte Funktionalität durch Spring AOP bereitgestellt wird.
Mittels der Spring-Klasse EhCacheManagerFactoryBean wird der Ehcache integriert.

Bibliotheken
In diesem Fall braucht man mindestens (und die entsprechende Abhängigkeiten):

• spring 2.5.6
• ehcache

XML Konfiguration
Die XML Konfiguration für Spring sieht wie folgt aus:

 <!-- ...some other spring configuration... -->

 <!-- Ehcache bean which gets the path the ehcache.xml config file -->
 <bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="configLocation" value="classpath:ehcache.xml" />
    </bean>

 <!-- Interceptor which handels the cross cutting concerns (here: caching) -->
 <bean id="coInterceptor" class="de.ic.jee.aop.COCacheInterceptor">
		<constructor-arg index="0" ref="cacheManager" />
  		<!-- Set the name of the cache which will be used from the cache manager -->
		<constructor-arg index="1" value="coCache" />
	</bean>

  <!-- Advisor for the relevant methods -->
    <bean id="coAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
		<property name="advice">
        	<ref local="coInterceptor"/>
		</property>
		<property name="patterns">
                  <!-- only the get and update methods -->
        	  <list>
        		<value>.*update.*</value>
        		<value>.*get.*</value>
        	  </list>
		</property>
	</bean>

  <!-- Proxy factory for aop proxy  -->
	<bean id="coServiceProxy" class="org.springframework.aop.framework.ProxyFactoryBean">
		<property name="target">
                        <!-- The target bean object -->
			<ref bean="coService"/>
		</property>
		<property name="interceptorNames">
			<list>
				<value>coAdvisor</value>
			</list>
		</property>
                <!-- Name of this new generated proxy, to identify this object
                       in the autowired process.
                -->
		<qualifier value="coServiceProxy"/>
	</bean>

Spring AOP ist proxy-basiert. Hierfür wird deswegen ein ProxyFactoryBean definiert, was den Advisor (coAdvisor) auf ein bestimmtes Bean einsetzt, somit entsteht dann eine neue Proxy-Klasse (coServiceProxy).

Mit RegexpMethodPointcutAdvisor kann definiert werden, welche Methoden beobachtet werden. In unserem Fall alle update und get Methoden.

Der Advice bzw. Interceptor (coInterceptor), welcher die Querschnitts-Funktionalität beinhaltet, kriegt eine Referenz auf den CacheManager (hier: cacheManager). Mit dieser Referenz kann beim Methoden-Aufruf vorher im Cache geprüft werden, ob die Antwort schon bekannt ist, wenn nicht, wird die Methode weiter ausgeführt und das Ergebnis (Rückgabewert) dann im Cache gespeichert.

public class COCacheInterceptor implements MethodInterceptor {

    private final CacheManager cacheManager;
    public COCacheInterceptor(final CacheManager cm, final String cn) {
		this.cacheManager = cm;
		this.cacheName = cn;
	}

     public Object invoke(final MethodInvocation methodInvocation) throws Throwable {

          /*
           * Cache cache = cacheManager.getCache(this.cacheName);
           * String cacheKey = .... generate cache key, maybe the arguments of the method invocation
           * get element from the cache
           * Element e = cache.get(cacheKey);
           * If element found:
           * - return e.getObjectValue()
           * otherwise:
           * - proceed the method, methodResult = methodInvocation.proceed()
           * - put the result in the cache, cache.put(new Element(cacheKey, methodResult));
           * - return methodResult;
           */

     } // invoke()
}

Mit wenig Konfiguration und Programmierung kann man sehr einfach Cache-Funktionalität einfügen, ohne die Business Logik zu verändern.

Links:
- Spring AOP: http://static.springsource.org/spring/docs/2.5.x/reference/aop-api.html
- Ehcache: http://ehcache.org/
- Spring 2.5.x API: http://static.springsource.org/spring/docs/2.5.x/api/index.html

• JSF 2.0: Mojarra in Version 2.0.0-b16
• Tomcat 6
• Maven
• Eclipse

Voraussetzung:

• JDK 6
• Tomcat 6
• Eclipse inklusive WTP, Maven (m2eclipse)
• Beim m2eclipse-Plugin “Maven integration for WTP” in Eclipse nachinstallieren, falls nicht vorhanden

Vorbereitung:

1. In Eclipse ein dynamische Webprojekt erstellen
2. Tomcat 6 als Server in Eclipse einrichten
3. Dem Projekt “Maven Nature” hinzufügen. Zur Zeit ist das Projekt ein reines Webprojekt ohne Maven Eigenschaften. Durch Rechte-Maustaste auf das Projekt und dann Maven > Enable Dependency Management wird Maven-Funktionalität für das Projekt hinzugefügt
4. Maven erwartet eine andere Ordner-Struktur als in dem WTP-Webprojekt. Als erstes muss der Source-Ordner angepasst werden. Hierfür müssen mind. folgender Ordner erstellt werden: src/main/java. Diesen muss man in Eclipse dann auch als Source-Ordner konfigurieren (Java Build Path)
5. Der WebContent-Ordner wird von Maven mit der WTP-Integration genutzt. Hier ist keine Veränderung/Anpassung notwendig
6. Die existierende pom.xml muss entsprechende Einträge erweitert werden. Für JSF 2 könnte das wie folgt aussehen:

   <project xmlns=&quot;http://maven.apache.org/POM/4.0.0&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xsi:schemaLocation=&quot;http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd&quot;>
     <modelVersion>4.0.0</modelVersion>
     <groupId>jsf2test</groupId>
     <artifactId>jsf2test</artifactId>
     <version>0.0.1-SNAPSHOT</version>
   
     <properties>
     	<version.jsf2>2.0.0-b16</version.jsf2>
     	<version.junit>4.4</version.junit>
     	<version.jstl>1.2</version.jstl>
     	<version.servlet>2.5</version.servlet>
     	<version.log4j>1.2.14</version.log4j>
     </properties>
   
     <repositories>
     	<repository>
   		<id>maven2-repository.dev.java.net</id>
   		<name>Java.net Repository for Maven</name>
   		<url>http://download.java.net/maven/2/</url>
   		<layout>default</layout>
   	</repository>
     </repositories>
   
     <build>
       <finalName>jsf2test</finalName>
       <plugins>
   	    <plugin>
   			<artifactId>maven-compiler-plugin</artifactId>
   			<configuration>
   			<source>1.5</source>
   			<target>1.5</target>
   			</configuration>
   		</plugin>
   
   	    <plugin>
   		  <groupId>org.mortbay.jetty</groupId>
   		  <!-- jetty 7
   		  <artifactId>jetty-maven-plugin</artifactId>
   		   -->
   		  <artifactId>maven-jetty-plugin</artifactId>
   		  <version>6.1.15</version>
   		  <!--
   		  <configuration>
   		    <scanIntervalSeconds>10</scanIntervalSeconds>
   		  </configuration>
   		   -->
   		</plugin>
       </plugins>
     </build>
   
      <dependencies>
      	<!-- JSF2 -->
   	<dependency>
   		<groupId>com.sun.faces</groupId>
   		<artifactId>jsf-api</artifactId>
   		<version>${version.jsf2}</version>
   	</dependency>
   
   	<dependency>
   		<groupId>com.sun.faces</groupId>
   		<artifactId>jsf-impl</artifactId>
   		<version>${version.jsf2}</version>
   	</dependency>
   
   	<dependency>
         <groupId>javax.servlet</groupId>
         <artifactId>jstl</artifactId>
         <version>${version.jstl}</version>
       </dependency>
   
       <dependency>
         <groupId>javax.servlet</groupId>
         <artifactId>servlet-api</artifactId>
         <version>${version.servlet}</version>
       </dependency>
   
   	<!-- Misc -->
       <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>${version.junit}</version>
         <scope>test</scope>
       </dependency>
   
       <dependency>
   	    <groupId>log4j</groupId>
   	    <artifactId>log4j</artifactId>
   	    <version>${version.log4j}</version>
   	</dependency>
   
     </dependencies>
   </project>
   

7. Die Bibliotheken, welche Maven bereitstellt, müssen beim Deploy in WEB/lib kopiert werden. Die Nutzung der Maven Dependencies geschieht durch folgende Einstellung: In den Eigenschaften des Projekts muss unter Java EE Module Dependencies die Maven Dependencies ausgewählt werden.
8. Web.xml für JSF anpassen. Z.B. wie folgt:

   <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?>
   <web-app xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xmlns=&quot;http://java.sun.com/xml/ns/javaee&quot; xmlns:web=&quot;http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd&quot; xsi:schemaLocation=&quot;http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd&quot; id=&quot;WebApp_ID&quot; version=&quot;2.5&quot;>
     <display-name>dynWebTest</display-name>
   
     <servlet>
       <servlet-name>Faces Servlet</servlet-name>
       <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
       <load-on-startup>1</load-on-startup>
     </servlet>
   
     <servlet-mapping>
       <servlet-name>Faces Servlet</servlet-name>
       <url-pattern>*.xhtml</url-pattern>
     </servlet-mapping>
   
     <!-- This parameter is also possible to set over JNDI -->
     <context-param>
       <param-name>javax.faces.PROJECT_STAGE</param-name>
       <param-value>Development</param-value>
     </context-param>
   
     <welcome-file-list>
       <welcome-file>index.html</welcome-file>
       <welcome-file>index.xhtml</welcome-file>
     </welcome-file-list>
   </web-app>
   

Nun steht das Grundgerüst bereit, um endlich mit JSF 2.0 anzufangen.
Für diejenigen, die mit JSF 1.x schon gearbeitet haben, werden wohl die faces-config.xml vermissen. Korrekt. Ist gewollt. Ist nämlich die erste Verbesserung von JSF 2.0! Die faces-config.xml kann immer noch verwendet werden, aber vieles ist durch Annotations möglich und die Navigation ist einfacher/verständlicher geworden. Später mehr dazu.

Vielleicht noch ein paar Worte zur Beispielanwendung: Die Beispielanwendung beinhaltet eine Seite, mit einem Input-Feld und zwei Select-Boxen. Man stelle sich folgendes Szenario vor: Man möchte ein Registrierungs-Formular erstellen, in dem der Nutzer überprüfen kann, ob der Username noch vorhanden ist. Zusätzlich soll er das Land auswählen können, in dem er lebt.

Controller:
Der Controller ist das ManagedBean, welches in den XHTML-Seiten verwendet wird und alle Anfragen verarbeitet.

@ManagedBean(name = "fc")
@RequestScoped
public class FrontController {

	private Person person;

	private String country;

	private String continent;

	private Map<String, String[]> countries;

	@ManagedProperty(value = &quot;#{authService}&quot;)
	private AuthService authService;

	public void isUsernameValid() {

		if(authService.isUsernameValid(person.getUsername())) {

			output = &quot;Username ist nocht nicht vorhanden&quot;;
		} else {
			output = &quot;Username ist schon vorhanden. Bitte einen anderen auswählen&quot;;
		}
	}

        public String[] getCountries() {
		// deliver the countries to the actual continent
		return countries.get(continent);
	}
       /* further get/set-Methods */
}

Durch die Annotations wird JSF mitgeteilt, dass es sich bei der Klasse um ein managed bean mit dem Namen fc handelt (@ManagedBean) und die jeweils immer nur für ein Request gültig ist (@RequestScoped, weitere Scops sind vorhanden). Früher hat man diese Einstellungen in faces-config.xml durchgeführt.
Neu ist auch @ManagedProperty. Mittels dieser Annotation wird die Dependency Injection Funktionalität von JSF 2.0 verwendet. In FrontController#authService wird nun das passende Objekt mit dem managed bean namen “authService” injiziert.
Hier sei anzumerken, dass JSF kein field access durchführt, sondern die getter/setter-Methoden verwendet um Properties zu setzen.

Die Domain-Klasse Person ist ein einfaches Bean bzw. POJO, und repräsentiert die einzugebenden Daten in dem Formular.

Zu dem Controller und Model Teil gehört noch die Präsentation und diese wird mittels Facelets durchgeführt. In JSF 2.0 ist Facelets die primäre Technologie zur Beschreibung des Views. Man kann natürlich JSP nutzen, wenn man den Sprung nicht durchführen möchte. Aber die Vorteile liegen eher bei Facelets!

<!DOCTYPE html PUBLIC &quot;-//W3C//DTD XHTML 1.0 Transitional//EN&quot;
        &quot;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd&quot;>

<html xmlns=&quot;http://www.w3.org/1999/xhtml&quot;
      xmlns:ui=&quot;http://java.sun.com/jsf/facelets&quot;
      xmlns:f=&quot;http://java.sun.com/jsf/core&quot;
      xmlns:h=&quot;http://java.sun.com/jsf/html&quot;>

<h:head>
  <title>JSF Demo</title>
</h:head>
<h:body>
  <h1>Register</h1>
  <h:form>

    <h:inputText id=&quot;name&quot; value=&quot;#{fc.person.username}&quot;>
    </h:inputText>
    <h:commandButton value=&quot;Check username&quot; action=&quot;#{fc.isUsernameValid}&quot;>
    	<f:ajax execute=&quot;name&quot; render=&quot;outIsUserValid&quot; />
    </h:commandButton>
    <h:outputText id=&quot;outIsUserValid&quot; value=&quot;#{fc.output}&quot; />
  </h:form>
  <br />

  <h:form>
                <!-- First select box to select the continent.... -->
  		<h:selectOneMenu value=&quot;#{fc.continent}&quot;>
  			<f:selectItems value=&quot;#{fc.continents}&quot; />
  			<f:ajax render=&quot;countrylist&quot; />
  		</h:selectOneMenu>

                <!-- ...and depending of the selected continent, contains this
                      second select box the countries
                -->
  		<h:selectOneMenu value=&quot;#{fc.country}&quot; id=&quot;countrylist&quot;>
  			<f:selectItems value=&quot;#{fc.countries}&quot; />
  		</h:selectOneMenu>
  </h:form>
</h:body>
</html>

Mittels Facelets ist die Beschreibung der Views reiner XML/XHTML.
In dem ersten Formular ist das Input-Feld, in dem der Nutzer überprüfen kann, ob sein Username schon vergeben ist. Die Überprüfung wird mittels Ajax durchgeführt. Hierfür ist der neue <f:ajax>-Tag zuständig. Beim betätigen des Buttons wird ein Ajax-Request verschickt, dieser beinhaltet die Werte aus den Felder in dem execute-Attribute. In unserem Fall aus dem Feld mit der ID name. Die Antwort wird, wie in dem render-Attribute definiert, in ID outIsUserValid eingefügt. Auf dem Server wird zur Verarbeitung die Methode FrontController.isUsernameValid() aufgerufen. Während des Aufrus ist FrontController#person mit den aktuellen Werten (hier: username) gesetzt.

In dem zweiten Formular gibt es zwei Select-Boxen. In dem einen kann ein Kontinent ausgewählt werden. Resultierend dazu, wird in der zweiten eine Liste von Ländern angezeigt. Diese Länder-Liste wird durch Ajax ermittelt.
In der ersten Liste ist wieder ein <f:ajax>-Tag zu finden. Bei dem 1. Beispiel wurde der Request verschickt, wenn der Nutzer den Button drückt. D.h. in der Javascript-Welt, beim Click-Event, wird der Request verschickt. Das <f:ajax>-Tag wählt immer das passende Event aus, abhängig von der Komponente, in dem es verwendet wird.
Bei Listen horcht es auf ein OnChange-Event. Natürlich kann man ein anderes Event festlegen, dafür gibt es das event-Attribut.
D.h. also, sobald in der ersten Liste die Auswahl verändert wird, wird die zweite Liste aktualisiert (durch render=”countrylist”). Auf dem Server wird FrontController.getCountries() aufgerufen. In dem Kontext ist FrontController#continent belegt, da der Nutzer eine Auswahl in der 1.Liste durchgeführt hat. FrontController.getCountries() liefert nun nur ein Array von Ländern zurück. Die korrekte Verschachtelung in HTML-Elemente (option-Tag) übernimmt JSF!

Fazit:

• Mittels JSF 2.0 hat man weniger Konfigurationsaufwand
• Durch den Einsatz von Facelets macht das Erstellen der HTML-Seiten wieder Spass. Hier kann man die vorhandenen HTML-Templates fast unverändert übernehmen…
• Unproblematischer Javascript/Ajax-Einsatz, ohne es wirklich zu merken!
• DI ohne Spring!

Also der erste Eindruck hat überzeugt. Wenn man JSF-Fan war, wird man JSF-Fan weiter bleiben. Wenn nicht, könnte man es jetzt bestimmt werden

• Andy Schwartz Blogeintrag Andy hat selbst eine Auflistung inklusive weitere Erklärung aufgeführt
• Mojarra: Get started
• Mojarra 2.0.0 Release Notes: Mit den Verweisen zu den aktuellen APIs, TLDs etc

Zu dieser Auflistung, die aktualisiert wird, folgen in dem Blog ein paar Beispiele zu speziellen Themen.

P.S.: In dem Block “Spec 2.0″ folgen demnächst Beiträge zu Spezifikationen, Frameworks die nun in Version 2.0 erschienen sind.

Um den/die Ordner durchzulaufen existiert ein DirectoryWalker.
Um den abstrakten DirectoryWalker nutzen zu können könnte man z.B. eine folgende Implementierung nutzen:

public class TestDirectoryWalker extends DirectoryWalker {

	public TestDirectoryWalker(IOFileFilter dirFilter, IOFileFilter fileFilter, int depth) {
		super(dirFilter, fileFilter, depth);
	}

        /**
          * This method sets the start directory and starts the DirectoryWalker.
          */
	public List search(File startDir) throws IOException {

		List results = new ArrayList();
		walk(startDir, results);
		return results;
	}

	protected boolean handleDirectory(File directory, int depth, Collection results) {
		// return true, cause every sub directory is allowed
		return true;
	}

	protected void handleFile(File file, int depth, Collection results) {		

                // we want only the files with the name "abc.txt" in the
                // subdirectories. This files will be inserted in the given
                // result collection. This collection is the same as the
                // created List in search(File)
		String filename = file.getName();
		if("abc.txt".equalsIgnoreCase(filename))
			results.add(file);
	}
}

Wie man sehen kann, kann man innerhalb weniger Zeilen einen DirectoryWalker schreiben, der alle Unterordner durchgeht und alle Dateien mit dem Titel “abc.txt” liefert.
Die Nutzung ist genauso simpel:

TestDirectoryWalker idw = new TestDirectoryWalker(DirectoryFileFilter.DIRECTORY, FileFilterUtils.suffixFileFilter(".txt"), 3);

		String startDir = "D:/Temp/.../blub";
		List files = null;
		try {
                        // search the directory for the wanted files
			files = idw.search(new File(startDir));
			System.out.println("Files: #" + files.size());

                        // sort the resulting files using the LastModifiedFileComparator
			System.out.println("first file: " + files.get(0));
			Collections.sort(files, LastModifiedFileComparator.LASTMODIFIED_COMPARATOR);

			System.out.println("oldest file: " + files.get(0));
		} catch (IOException e) {
			e.printStackTrace();
		}

Der Konstruktor TestDirectoryWalker(IOFileFilter, IOFileFilter, int) erwartet zwei Filter, einen für die Ordner und einen für die Dateien. Die Auswahl ist umfangreich, ansonsten kann man auch seinen eigenen schreiben.

Als letztes ist vielleicht noch die Zeile

Collections.sort(files, LastModifiedFileComparator.LASTMODIFIED_COMPARATOR);

interessant. LastModifiedFileComparator ist wie der Name schon andeutet, eine Klasse welches Comparator implementiert bzgl. File.lastModified(). Die Liste mit den gefundenen Dateien wird aufsteigend sortiert.

Innerhalb weniger Minuten kann man verschiedene Ordner nach speziellen Dateien suchen. Dank Apache Commons IO.