JSF Für die Ausgabe von dynamischen HTML-Seiten eines Webservers verwendet man im Javaumfeld üblicher Weise JavaServer Pages (JSP). Damit wird die Einbettung von Javacode - und somit von dynamischem Inhalten - in HTML-Seiten ermöglicht. Die Vermischung von Java- und HTML-Code führt allerdings schnell zu einer unübersichtlichen Programmstruktur, die die Entwicklung deutlich verkompliziert. Um die Entwicklung von Webseiten zu vereinfachen, wurden Web-Frameworks wie zum Beispiel Struts \cite{struts} oder eben JavaServer Faces (JSF) entwickelt. Beide benutzen das Model-View-Controller-Architekturmuster (MVC). In der Anwendung werden die Daten (model), die Präsentation (view) und die Programmsteuerung (controller) voneinander getrennt. JSF ist hauptsächlich für die Präsentation zuständig und verfolgt zusätzlich einen komponentenbasierten Ansatz. Bei komponentenbasierter Programmierung wird versucht die Anwendung in wiederverwendbare Komponenten zu unterteilen, um dann später diese Bausteine zu Anwendungen zusammenzusetzen. Ein typisches Beispiel ist eine Tabelle, deren Eigenschaften in einem Objekt gespeichert sind und der man eine Liste der darzustellenden Objekte zuordnet. Diese Komponente fügt man dann in der Seite ein, immer wenn man eine Liste dieser Art verwenden möchte, anstatt den Quellcode der Tabelle selbst zu erstellen. In dieser Arbeit wird JSF verwendet, da es im Gegensatz zu den anderen Frameworks standardisiert und Teil der Java EE 5 Spezifikation ist. JSF wird eine weite Verbreitung in Enterprise-Projekten nachgesagt und es heißt, JSF sei auch einfacher zu lernen als Struts.(siehe hierzu die Diskussion unter http://tech.groups.yahoo.com/group/novajug/message/9812) Es gibt viele verschiedene Implementierungen und Komponenten-Bibliotheken wie zum Beispiel MyFaces von Apache, RichFaces von Exadel, ICEfaces von ICEsoft oder ADF Faces von Oracle. In dieser Arbeit wird jedoch die Referenzimplementierung von Sun verwendet, um unabhängig von Herstellern zu bleiben. Der vollständige Verzicht auf ein Web-Framework und die Programmierung nur mit JSPs ist zwar möglich, wird aber den Möglichkeiten nicht gerecht, die man mit Java EE 5 hat.

Facelets JSP ist darauf ausgelegt dynamische Ausgaben zu generieren. JSF verwendet JSP jedoch zur Erstellung und Verwaltung von Komponenten. Die Kombination von JSP und JSF bringt somit ein paar Schwierigkeiten mit sich. Jedoch kann man auf JSPs verzichten und statt dessen eine andere Technologie verwenden. Facelets ist eine solche Technologie und wird als Open Source Projekt unter der Aufsicht von Sun entwickelt. Die Beliebtheit des Projektes hat dazu geführt, dass über eine Aufnahme von Facelets in der zukünftigen Spezifikation JSF 2.0 (JSR 314) diskutiert wurde. Facelets werden inzwischen zwar im JSR erwähnt, aber nicht komplett übernommen. Es ist deutlich zu erkennen, dass JSF und Facelets ein gutes Team bilden und der komplette Verzicht auf JSP viele Vorteile bringt. Facelets bieten Templating (Die Aufteilung der Webseite in einzelne Bestandteile wie zum Beispiel Header, Navigation, Content und Footer), bessere Debugmöglichkeiten durch Fehlermeldungen mit genauer Angabe der Fehlerquelle, vereinfachte Erstellung von Komponenten und noch einige andere Features. Daher wird in dieser Arbeit auf JSP verzichtet und die aktuelle Version von Facelets verwendet.

Chapter 12 in the book "Pro EJB 3: Java Persistence API" by Mike Keith and Merrick Schincariol was very useful for me.

I'm using Netbeans 6.0, EJB3, JPA and a MySQL-Datebase and i write integration tests. (as defined in the book above: focus on use-cases, decoupled from appserver, making full use of external resources such as database)

First of all i added the library JUnit (4.1) to my Netbeans-Project You can then rightclick on a sourcefile and select > Tools > Create JUnit Tests

Using the Entity Manager
If you're using the Entity Manager (EM) you must create one for your tests. Because no AS is around, you need an EM Factory and for that you need a Persistence Provider. Add the library TopLink Essentials to the project. Without the AS we cant use JTA datasource with JNDI, so i created a mysql testdatabase and added a persistence-unit for testpurposes. To use it i need the MySQL JDBC Driver-library in my project.
My persistence.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" 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 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
  <persistence-unit name="Project-ejbPU" transaction-type="JTA">
    <jta-data-source>jdbc/project_database_jndi_name</jta-data-source>
  </persistence-unit>
  <persistence-unit name="ProjectTest-ejbPU" transaction-type="RESOURCE_LOCAL">
    <class>project.model.entity1</class>
    <class>project.model.entity2</class>
    <class>project.model.entity3</class>
    <class>project.model.entity4</class>
    <class>project.model.entity5</class>
    <properties>
        <property name="toplink.ddl-generation" value="create-tables"/>
        <property name="toplink.jdbc.driver" value="com.mysql.jdbc.Driver" />
        <property name="toplink.jdbc.url" value="jdbc:mysql://localhost:3306/project_test_db_name" />
        <property name="toplink.jdbc.user" value="root"/>
        <property name="toplink.jdbc.password" value="xxx"/>
     </properties>
  </persistence-unit>
</persistence>

Note that the transaction-type should be RESOURCE_LOCAL and not JTA, because we dont want any trouble with JNDI-stuff ;) I've been told that every entity has to be defined explicitly in the persistence.xml

Now you need to create and use the EM in your tests
Change the setUp()-method in the testclass to the following:

    @Before
    public void setUp() {
        yourbean.em = Persistence
.createEntityManagerFactory("ProjectTest-ejbPU")
.createEntityManager();
        // your own setUp-stuff
    }

def test_should_destroy_rating assert_difference('Rating.count', -1) do delete :destroy, :id => ratings(:one).id end assert_redirected_to ratings_path end

one: date: 2008-01-10 02:30:05 rating: 5000 status: COMPLETED customer: one

create_table :ratings do |t| t.datetime :date t.integer :rating t.string :status t.references :customer t.timestamps end

def test_should_destroy_fact_type assert_difference('FactType.count', -1) do delete :destroy, :id => fact_types(:fact_type_1).id end assert_redirected_to fact_types_path end

id,factCategory_id,title,question,question_type 1,2,"Alter des Kunden","Wie alt ist der Kunde?","FREE"

create_table :fact_types do |t| t.string :title t.text :question t.string :question_type t.references :factCategory t.timestamps end

MySQL Error: #42S22Unknown column 'facts.fact_type_id' in 'where clause': SELECT * FROM `facts` WHERE (facts.fact_type_id = 1)

1. Motivation
   Warum mache ich das Ganze?
2. Problemstellung
   Und wo liegt das Problem?
3. Aufbau

1. Web Engineering
2. Metriken
   Was sind Metriken und welche verwende ich?
3. Programmiersprachen
   Wo gibt es Unterschiede und warum ist das relevant?

1. Java EE
1. Java
   Hauptmerkmale der Sprache
2. Zielsetzung
   Wozu ist JavaEE gedacht?
3. Konzept
   Hier wird auf den Application Server eingegangen
4. Komponenten
   Hier werden die Komponenten beschrieben, die ich verwende
5. Werkzeuge
   ...und hier die Werkzeuge (Netbeans)
2. Ruby on Rails
1. Ruby
   Hauptmerkmale der Sprache
2. Zielsetzung
   Was will Rails erreichen?
3. Komponenten
   Welche Komponenten beinhaltet Rails?
4. Struktur
   MVC und so
5. Werkzeuge
   Aptana/Konsole/Vielleicht ein Blick auf Netbeans
3. Ein erster Vergleich
   Ausarbeitung der markantesten Unterschiede. Bewertung aber erst in Kapitel 5

1. Rating
   Was ist überhaupt ein Rating?
2. Grundversion
1. Anforderungen
2. Vorarbeiten
   Datenmodellierung
3. Umsetzung
   Hier ist noch offen, wie der Abschnitt aussehen soll. s.u.
3. Erste Erweiterung
1. Anforderungen
2. Umsetzung
4. Zweite Erweiterung
1. Anforderungen
2. Umsetzung

1. Metriken
   Die gesammelten Daten werden analysiert
2. Besondere Aspekte
3. Eindruck
   subjektive Bewertung

1. Zusammenfassung
2. Fazit
3. Ausblick

"Unsere Anstrengungen auf die OOXML (Office Open XML) Standardisierung Einfluss zu nehmen, waren bislang höchst erfolgreich. Im Februar wollen wir die 100.000 Unterschriften-Marke erreichen, wenn in Genf das fünftägige Ballot Resolution Meeting (BRM) zur Behandlung der eingereichten Kommentare und endgültigen Abstimmung über OOXML stattfindet. Microsoft versucht mit allen Mitteln seinen "Standard" ohne fundamentale Änderungen verabschieden zu lassen, trotz tausender offiziell vorgebrachter Kommentare über technische Mängel und der Existenz von ISO 26300:2006 (OpenDocument, ODF) als angemessenen Nachfolger für die proprietären Microsoftformate (doc, ppt und xls) im Bürobereich." - FFI e.V