voodoo bits

Comparing Database Structures

2009-07-05T18:35:00.084+02:00

Overview

(Deutschsprachige Anleitung in liesmich.txt)

Djembe helps in keeping the structures of several database for development, testing, integration and production synchronized
Database independent due to the usage of JDBC drivers
Compare databases offline
Export results to Excel
Structures are saved as XML, thus allowing any further processing
usable via command line or with its own GUI

Environment:

Java 6 or newer
JDBC Driver (drivers for Oracle, MS SQL Server, Postgres, MySQL, Derby/JavaDB and Firebird were tested successfully)

Verified for Windows XP SP3 and openSUSE 11.

The main two components are:

The scanner analyzes database structures and saves them as xml files.
The comparer reads previously stored xml scans and writes the comparison result as plain text log files, respectively presenting the result as GUI table.

Both components are configured via plain text property files:

file suffix .djs for scanners
file suffix .djc for comparisons

Currently, the following database objects are processed:

Tables with columns and privileges
Views with columns and privileges
Columns with type, length, and nullable flag
Sequences/generators with privileges
Oracle synonyms
Trigger (without source code so far)
Primary- and foreign keys
Indexes
Types

(Privilege, type, trigger and other vendor specific scanners are not part of the
free standard edition)

Usage

For installation, just copy the application folder to the desired place and add the required JDBC drivers (to the "lib" folder usually).
Please don't forget to copy your license key "djembe-license.txt" into the root folder of the application.

java -jar djembe.jar 
-ui | 
-scan [scan-properties] | 
-compare [compare-properties]

-ui
Launches the graphical user interface of Djembe.

-scan
Reads a database and stores its structure as xml file.

-compare
Compares two databases.

Examples:
java -jar djembe.jar -scan scan-my-db.djs
java -jar djembe.jar -compare compare-my-dbs.djc

Under Windows, you can use "djembe.exe" or "djembe.bat", under linux "djembe.sh" for running the graphical user interface as well.

Privilege markup in scans and comparison results:
[grantor] -> [grantee]: [privilege]

Column Aliases:
They allow to look at different data types as synonyms causing no difference alert.
A typical example would be to equalize Oracle's specific "varchar2" and the standard "varchar".
You can set up as many mappings as you like, each one comma separated:

[mapping-1], [mapping-2], ..., [mapping-n]

Data types and flags are separated by spaces:

[Leading data type] [-is] [-id] [Alias-1] ... [Alias-n]

Flags:
-id ignore digits
-is ignore size

Example:
"int4 -id -is number numeric, varchar2 varchar"

Fields of type "int4" are put together with "number" and "numeric".
Both size and number of digits are ignored.
Additionally, data types "varchar2" and "varchar" are taken as identical.

Useful mappings:
varchar2 varchar,
int4 -id -is number numeric,
boolean -id -is char,
date -id -is timestamp,
blob -is bytea,
bpchar char,
numeric number

Scanner-Properties

url =             (database URL to analyze)
alias =           (short database name, free to choose)
driver =          (JDBC driver class)
driverUrl =       (JDBC driver URL)
user =            (database user, might need administrator rights !)
schema =          (database schema)
filter =          (name filter for tables, views, etc.)
scanner.classes = (comma separated list of scanner classes to run)
replace =         (automatically replaces written xml result file, true oder false)
exportName =      (name pattern of the written xml file)

Folder "templates" contains several sample property files for various databases like Oracle, Postgres or MySql.

Comparer-Properties

comparer.log.charset =           (charset of the generated log file)
comparer.ignoreIndexNames =      (ignore index names, true oder false)
comparer.log.name =              (name pattern of the generated log file)
comparer.ignoreForeignKeyNames = (ignore foreign key names, true oder false)
comparer.ignorePrivileges =      (ignore privileges, true oder false)
comparer.ignorePrimaryKeyNames = (ignore primary key names, true oder false)
comparer.ignoreColumnTypes =     (ignore data types, true oder false)
comparer.ignoreSchemas =         (ignore schemas, true oder false)
comparer.database.1 =            (first, previously scanned database as xml)
comparer.database.2 =            (second, previously scanned database as xml)
comparer.log.replace =           (automatically overwrite the generated log file, true oder false)
comparer.column.aliases =        (mappings for column aliases)
comparer.log.separator =         (separator char of the generated log file)

Available Scanner

default.TableScanner
default.ViewScanner
royalty.TypeScanner

oracle.SequenceScanner
oracle.SynonymScanner
oracle.TriggerScanner

postgres.SequenceScanner
postgres.DomainScanner
postgres.TriggerScanner

firebird.GeneratorScanner
firebird.TriggerScanner

mysql.TriggerScanner

derby.SynonymScanner

File Suffixes

.djs = scanner configuration
.djc = comparison configuration
.djd = database dump

Get it here:

Downloads

Soon to come:
Professional version with more scanners for privileges, types, triggers and other vendor specific objects.

Neues auf Java basierende Portal freigeschaltet

2009-06-02T12:53:00.006+02:00

Gestern konnte endlich das neue Künstlerportal Artist Jobs freigeschaltet werden.

Technologische Basis ist wie folgt:
- Java 5
- Spring (komplette Konfiguration mittels Dependency Injection, Cron Jobs)
- Hibernate
- Postgres 8.3
- JSF mit den RichFaces (inklusive Ajax)
- YAML (CSS-Unterstützung, Aufteilung der Seiten in verschiedene Bereiche, IE-Hacks)
- iText (Rechnungserstellung)
- JRoots (Dynamische JSF-Tabellen, -Controller und -Security, Hibernate-Wrapper)
- Apache HttpClient (für die Anbindung des externen Zahlungsdienstleisters)
- JWPlayer als Flash-Player
- Log4J
- JUnit
- POI (initialer Import von Strukturdaten aus Excel-Sheets)
- Apache Tomcat als Servlet Container
- Apache HttpServer als Webserver
- Linux mit OpenSuse 10 auf dem Root-Server

Anforderungen
- Webseiten sind durchgehend mit relativen Bildschirmbreiten gestaltet
- Jeder Benutzer kann mehrere Seiten des gleichen Typs, aber unterschiedlichen Objekten bzw. Inhalten parallel sichten und pflegen (Stichwort "Page Scope")
- Der Registrierungsprozess für neue Benutzer ist mehrstufig (Versand von Bestätigungsmails)
- Die Zahlungsabwicklung muß selbständig periodisch Mitgliedsbeiträge einziehen können, dabei Rechnungen generieren, versenden und auf abgelehnte Zahlungen reagieren
- Bei Uploads von Dateien muß der Dateityp anhand von "Magic Bytes" überprüft werden
- Versuche, HTML-Tags in Felder einzugeben, muß verhindert werden
- Benutzereingaben werden niemals in SQL-Strings direkt eingebettet, es werden immer Prepared Statements verwendet
- Für zeitkritische Suchanfragen muß händisch optimiertes SQL möglich sein, oder, noch weiterführend, die Umgehung von Hibernate durch Austausch der verwendeten DataFactory (einfache Umkonfiguration in Spring-Dateien)
- Einige Daten, die die Benutzer beispielsweise in Drop-Down-Boxen präsentiert bekommen, müssen in mehreren Sprachen vorliegen. Die Spracheinstellung der Benutzer entscheidet, welche Daten herangezogen werden.
- Die Datenbank muß täglich automatisch gesichert werden (über einen Linux-Cron Job und FTP)

Anmerkungen, Probleme, Lösungen

File-Uploads

Aus angedachten 1-2 Stunden wurden mehrere Tage. Es war anfänglich nicht möglich, größere Dateien ohne Abbruch auf den Rootserver zu übertragen. Offenbar ein Problem in der Kommunikation zwischen Webserver und Tomcat. Googlen brachte zwar einige ähnliche Fälle hervor, jedoch keine Lösung.
Die Lösung war dann jedoch simpel: nach dem Wechsel vom Apache Commons FileUpload zur RichFaces fileUpload-Komponente gab es keine Abbrüche mehr - ohne etwas an der Konfiguration zwischen Tomcat und Webserver zu ändern.
Allerdings sollte der Spaß noch nicht vorbei. Was nun mit dem FireFox funktionierte, brachte den Internet Explorer zum Stillstand: nach erfolgtem Upload fror der IE ein und war nur noch mit Gewalt zu beenden. Allerdings offenbar nur mit der Version meines Entwicklungsrechners. Andere Leute mit dem IE6 haben keine Probleme...

Flash, Ajax, HTML, JavaScript

Eine zuweilen unseelige Kombination. Es musste nach Auswahl eines Eintrags ein Flashplayer mit neuen dynamischen Inhalten versorgt werden. Ein Albtraum aus JSF, Ajax-Repaints, Hidden Fields und Redirects.
Funktioniert nun nach etlichem Gefrickel aber doch.
Meistens werden die Repaint-Aufforderungen der RichFaces brav befolgt. Manchmal jedoch auch nicht. Auch nach weiterem Probieren nicht. Oder auch längerem Probieren. Dann bleibt nur ein primitiver Redirect, um Seiteninhalte zu aktualisieren.

Mail-Versand

Eigentlich eine simple Sache. Spring bietet einen Wrapper für die Java Mail-API. Es war jedoch unmöglich, sich beim Provider zu authentifizieren. Die Mail-API bietet verschiedene Möglichkeiten dafür, von denen letztendlich nur eine (bei direkter Verwendung ohne Spring) erfolgreich war.

Lasttest
Nach dem ersten Test mit JMeter zeigte sich schnell eine Optimierungsmöglichkeit: Die auf ersten Seite angezeigte Tabelle wird nun nicht mehr ad hoc aus der Datenbank aufgebaut, sondern aus einem Cache angefordert, der initial beim Hochfahren des Servers gefüllt wird, sowie anschließend bei allen mit den Daten verbundenen Speicheraktionen aktualisiert.
Weiterhin werden Objekte für Drop-Down-Boxen vorbereitet: Hier werden nicht die reinen Daten vorgehalten, sondern fertig nutzbare SelectItem-Objekte.
Als Drittes werden die Strukturen von dynamisch erzeugten JSF-Tabellen vorgehalten.

Datenbank-Sessions

Um Probleme mit lazy-geladenen Hibernate-Objekten zu vermeiden, versorgt ein Servlet-Filter jeden Request mit einer gültigen Datenbankverbindung und schließt am Ende des Requests selbige wieder bzw. gibt diese frei.

Erstellen der Datenbank

Dazu gehört die Versorgung mit initialen Strukturdaten. Diese liegen in Excel-Sheets vor und werden mittels POI einmalig in die Datenbank übernommen.

Zahlungsabwicklung

Zum Einzug von Zahlungen wird über den Apache HttpClient die externe Schnittstelle des Zahlungsdienstleisters aufgerufen. Im Gegenzug lauscht ein Servlet auf Rückmeldungen, die über Erfolg oder Misserfolg berichten und kann dann entsprechend reagieren(z.B. Mails versenden, Benutzer sperren, etc.).

Cron Jobs

Sollte es im laufenden Betrieb zu Problemen in der Anbindung externer Dienste (z.B. für Mail oder Zahlungen) kommen, sorgen verschiedene Jobs mit Hilfe von Spring Schedulern dafür, daß zugehörige aufgelaufene Aufgaben dennoch abgearbeitet werden.

Various small how-tos for the JSF beginner

2009-02-01T17:28:00.009+01:00

A - Changing the locale of the current running session

1. Set up a managed session bean for storing the locale.

2. Intialize the locale from the browser settings:

public SessionBean() {
   FacesContext context = FacesContext.getCurrentInstance();
   HttpServletRequest request =
      (HttpServletRequest)context.getExternalContext().getRequest();
   sessionLocale = request.getLocale();

   if (!Locale.GERMAN.equals(sessionLocale) &&
       !Locale.ENGLISH.equals(sessionLocale)) {
      sessionLocale = Locale.ENGLISH;
   }
}

Make sure to fall back to your default locale in case of unknown locales.

3. Implement a simple getter and setter for the locale:

public Locale getLocale() {
   return sessionLocale;
}

public void setLocale(Locale sessionLocale) {
   this.sessionLocale = sessionLocale;
}

4. In every JSF page, ask for the current locale:

<f:view locale="#{sessionBean.locale}">

5. For switching the locale, add flag buttons or a user profile form.

B - Redirect to another place

void redirect(String url) {
   FacesContext context = FacesContext.getCurrentInstance();
   HttpServletResponse response = (HttpServletResponse)context.getExternalContext().getResponse();
   String path = context.getExternalContext().getRequestContextPath();
   response.sendRedirect(path + url);
}

The url given does not contain the application's context as prefix

C - Get a resource text for the current locale:

String getResourceText(String key) {
   String text = null;

   String bundleName = FacesContext.getCurrentInstance().getApplication().getMessageBundle();
   Locale loc = FacesContext.getCurrentInstance().getViewRoot().getLocale();
   ResourceBundle bundle = ResourceBundle.getBundle(bundleName, loc);

   try {
      text = bundle.getString(key);
   }
   catch (MissingResourceException e) {
      log.error(e);
      text = "! " + key + " !";
   }

   return text;
}

D - Get current session id

public String getSessionId() {
   FacesContext context = FacesContext.getCurrentInstance();
   return ((HttpSession)context.getExternalContext().getSession(false)).getId();
}

E - Get a request parameter

Object param = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("theParam");

F - Clear input of text fields and selected drop-down-lists

public void clearFields() {
   UIViewRoot uiRoot = FacesContext.getCurrentInstance().getViewRoot();
   recurseChildren(uiRoot);
}

protected void recurseChildren(UIComponentBase comp) {
   for (int i = 0; i < comp.getChildren().size(); i++) {
      UIComponentBase child = (UIComponentBase)comp.getChildren().get(i);
      recurseChildren(child);
   }

   if (comp instanceof HtmlInputText || comp instanceof HtmlInputTextarea || comp instanceof HtmlSelectOneMenu) {
      ((UIInput)comp).setValue("");
   }
}

G - Clean up expired sessions

1. Write a session listener:

public class CleanupListener implements HttpSessionListener {
   public void sessionCreated(HttpSessionEvent event) {
   }

   public void sessionDestroyed(HttpSessionEvent event) { 
      // clean up right here ... 
   }
}

2. Register the listener in the web.xml:

<listener>
   <listener-class>
      the.full.package.name.CleanupListener
   </listener-class>
</listener>

H - Fix the character encoding
If you get wrong page encodings for JSF post requests although you specified the content in every single page, setting up a servlet filter helps. Example to force UTF-8:


public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
   response.setCharacterEncoding("UTF-8");
   request.setCharacterEncoding("UTF-8");

JSF & Security

2008-04-16T15:32:00.023+02:00

This article introduces a Java module which utilizes phase listeners for securing JSF applications.

Feature list:

user, password and role based
interfaces throughout for independence of concrete implementations
easy to integrate into a Spring framework environment
supports password and cookie encoding
login data can be placed in cookies for automatic user logins
a special navigation handler ensures that invalid navigation rules do not open security holes
users may be allowed to login to multiple sessions or not

Introduction

The security core is independent of JSF. Thus, it could be used for other view technologies as well as for any view-independent access control. This affects all classes for authentication, authorization, access rules and cryptography.

How does it work ?

We have identities, usually representing application users. Identities are grouped by assigning roles. Access rules define which roles
are required to path through to certain views.
The authenticator is responsible for identifying users, whereas guards process authorization requests and either approve or refuse them.

Guards do not know whether access requests represent web sites or anything else. They just follow their given rules to make decisions.
Thus, other implementations of Guard and Rule are possible, for example to secure single UI components.

The following two classes allow the integration of the security core into JSF:

SecurityListener is a phase listener working in the RESTORE_VIEW phase
the LoginService is responsible for logins, cookies and creating identities respectively user objects

For denied requests two cases must be distinguished:

The user is not logged in. If so, the loginRequiredNavigation of LoginService returns the new navigation.
The user was logged in or can be logged in automatically. Then,
- the Guard delivered the violated rule, its errorView is taken as navigation target
- property defaultErrorNavigation of LoginService represents the fallback for rules without error view

In either case, if no valid target can be obtained or any exception raises, a 403-HTTP error is sent.

Configuration

Sample Spring configuration:

The default navigation handler of JSF is ignorant of invalid navigation rules. Non-existing rule outcomes result in no navigation at all, meaning that view requests which have just been denied, would pass through nevertheless.
The AssertingNavigationHandler takes care of this problem: an InvalidNavigationRuleException is thrown in case of an unknown or maybe just misspelled navigation directive.

<navigation-handler>
   de.voodoosoft.jroots.ui.jsf.core.AssertingNavigationHandler
</navigation-handler>

(faces-config.xml)

To be able to configure the SecurityListener as Spring bean, the following listener delegate must be installed:

<lifecycle>
   <phase-listener>
      de.voodoosoft.jroots.ui.jsf.core.DelegatingPhaseListenerMulticaster
   </phase-listener>
</lifecycle>

(faces-config.xml)

The DelegatingPhaseListenerMulticaster automatically searches Spring's application context for registered phase listeners like this:

<bean id="securityListener"
   class="de.voodoosoft.jroots.ui.jsf.security.SecurityListener">
   <property name="loginService" ref ="loginService"></property>
   <property name="guard" ref="guard"/>  
   <property name="defaultErrorNavigation" value="login"></property>
</bean>

Download and Example

The complete package jroots-jsf-security.zip with a full working example (folder /examples/example4) and sample Spring configurations can be downloaded here: JRoots Application Bricks

Dynamic JSF tables

2008-04-04T14:56:00.025+02:00

Here, I like to present a small open source library allowing to dynamically create JSF tables with Java code instead of using JSP tags.
JSP pages tend to get clumsy and not very easy to get at first sight, so we benefit from smaller files, more dynamic views as well as from the decouplement of pages and underlying bean properties.

Features

The required table structure (shown columns) can be put together by manual coding or automatically from processing properties of a given Java bean.
Column labels can be retrieved from assigned resource files.
The concrete component classes used are externally configured, for example with Spring, thus leaving the table factory independent of various JSF libraries and making it possible to switch the UI without complex engagement.
Numeric columns get right aligned by default.

At present there are the following column types:

Standard-Text
Link
Checkbox
Drop-Down (<select>-Tag)
Image

If these column types are not sufficient, additional individually built columns can be integrated as well.

Packages:

de.voodoosoft.jroots.ui.jsf.factory.table
de.voodoosoft.jroots.ui.jsf.factory.table.impl

Dependencies:

de.voodoosoft.jroots.ui.jsf.core
de.voodoosoft.jroots.core.annotations

Example jroots-example1
(configured with Spring's dependency injection):

What is left inside the JSP is the raw table without columns but with bindings for both the table component and the presented data.

<h:dataTable id="customerList"
   binding="#{customerController.dataTable}"
   value="#{customerController.beanData}"
   var="rowBean">
</h:dataTable>

In order to resolve Spring beans placed in JSP pages, the following configuration is required:

web.xml:

<listener>
   <listener-class>
      com.sun.faces.config.ConfigureListener
   </listener-class>
</listener>

<listener>
   <listener-class>
      org.springframework.web.context.ContextLoaderListener
   </listener-class>
</listener>

faces-config.xml:

<variable-resolver>
   org.springframework.web.jsf.DelegatingVariableResolver
</variable-resolver>

The UI-controller is defined inside Spring'S application context:

<bean id="customerController"
   class="de.voodoosoft.jroots.examples.example2.ui.jsf.customer.CustomerController"
   scope="request">
   <property name="tableFactory" ref="tableFactory"/>
</bean>

Dependency injection is used to assign the used TableFactory to the controller:

public class CustomerController {
    public void setTableFactory(TableFactory factory) {
        this.factory = factory;
    }

    private TableFactory factory;

When JSF asks for the table component, it gets built by the TableFactory:

public class CustomerController {
   public UIData getDataTable() {
      if (dataTable == null) {
         TableDefinition tableDef = factory.buildDefinition(CustomerBean.class);
         dataTable = factory.buildTable(tableDef);
      }

      return dataTable;
   }

The table structure follows the properties of the given bean, in this example name and address:

public class CustomerBean {
   public CustomerBean(String name, String address) {
      this.name = name;
      this.address = address;
   }

   private String name, address;

The second example jroots-example2 demonstrates the usage of RichFaces components instead of the reference implementation. All that has to be done is to modify the application context: properties of tableFactory and columnBuilder get component classes of RichFaces:


<bean id="tableFactory"
   class="de.voodoosoft.jroots.ui.jsf.factory.table.impl.DefaultTableFactory">
   <property name="resourceTag" value="res"/>
   <property name="rowBeanTag" value="rowBean"/>
   <property name="uiDataClass" value="org.richfaces.component.html.HtmlDataTable"/>
   <property name="columnBuilder">
      <map>
         <entry key="de.voodoosoft.jroots.ui.jsf.factory.table.ColumnDefinition" value-ref="defaultColumnBuilder"/>
      </map>
   </property>
</bean>

Finally, the third example jroots-example3 shows generation of link and drop-down columns. There are annotations for both column types. However, there is no need to use those, you can define any column by manual coding as well:

public class Guitar {

   @Link
   private String name;

   @DropDown(targetEntity = Wood.class)
   private Long bodyWood;

   @DropDown(targetEntity = Wood.class)
   private Long neckWood;

Links can either be mapped to controller methods (formSubmit = true) or point to external targets. Link targets are set inside the controller:

Internal Link:

LinkColumnDefinition linkCol = tableDef.getColumn("name");
linkCol.setTarget("#{guitarController.onGuitarClicked}");

External Link:

linkCol = new LinkColumnDefinition("google");
linkCol.setOutput("google");
linkCol.setFormSubmit(false);
linkCol.setTarget("http://www.google.de/search?q=#{guitarController.dataTable.rowData.name}");
tableDef.addColumn(linkCol);

Here we have the characteristic that controller properties are evaluated and passed as URL parameters. To access the current row bean, getRowData() of UIData is invoked in this example.

Spring configuration:

Download:

All the involved jar files

jroots-core.jar
jroots-jsf-core.jar
jroots-jsf-factory.jar

and the presented examples are available for download: voodoosoft

Frühlingsgesichter - JSF und Spring

2008-03-27T15:41:00.004+01:00

Spring-Beans lassen sich leicht in JSF-Seiten verwenden.

Im folgenden Beispiel soll der customerController nicht als normale Managed Bean sondern als Spring-Bean definiert werden:

<h:inputText value="#{customerController.name}"/>

1. spring.jar

Kopieren in den Ordner WEB-INF/lib

2. web.xml

In der web.xml den Pfad zur Spring-Konfiguration festlegen, beispielsweise:

<web-app>
   <context-param>
       <param-name>contextConfigLocation</param-name>
       <param-value>classpath:config/applicationContext.xml</param-value>
   </context-param>

  <listener>
     <listener-class>
        org.springframework.web.context.ContextLoaderListener
     </listener-class>
  </listener>

  (...)

</web-app>

3. faces-config.xml

Der DelegatingVariableResolver dient zur Auflösung der in den JSF-Seiten benutzten Beans:

<faces-config>
  <application>
     <variable-resolver>
        org.springframework.web.jsf.DelegatingVariableResolver
     </variable-resolver>
  </application>

  (...)

</faces-config>

4. Beans für den Application Context

Die JSF-eigene Definition als Managed Bean entfällt - stattdessen wird eine Spring-Bean konfiguriert:

<beans (...) >

 (...)

 <bean id="customerController"
      class="whatever.package.CustomerController"
      scope="request">
  </bean>

</beans>

JSF und die Keksfabrik

2008-03-22T22:21:00.003+01:00

Eine kurze Übersicht über die Behandlung von Cookies unter Java und JSF:

Erzeugen:

public void bakeCookie(FacesContext ctx) {
  Cookie cookie = new Cookie("tastyCookie", "mySecretCookieData");
  cookie.setMaxAge(604800); // Haltbarkeit in Sekunden

  HttpServletResponse response = (HttpServletResponse) ctx.getExternalContext().getResponse();
  response.addCookie(cookie);             
}

Die eigentlichen Daten sollten selbstverständlich verschlüsselt sein. Weiterhin sollte man in der Verwendung von Sonderzeichen Vorsicht walten lassen - diese könnten je nach Browser zu eigentümlichen Verhalten führen (richtig, genau der Browser).

Auslesen:

public boolean tasteCookie(FacesContext ctx) {
  Map cookieMap = ctx.getExternalContext().getRequestCookieMap();
  Cookie cookie = (Cookie)cookieMap.get("tastyCookie");
  if (cookie != null && cookie.getValue().length() > 0) {
     // enjoy cookie
     String val = cookie.getValue();
  }
}

Entsorgen:

public void eatCookie(FacesContext ctx) {
  Cookie cookie = new Cookie("tastyCookie");
  cookie.setMaxAge(0);

  HttpServletResponse response = (HttpServletResponse)ctx.getExternalContext().getResponse();
  response.addCookie(cookie);      
}

JSF und die wesentlichen Bestandteile einer Bohne

2008-03-22T20:45:00.009+01:00

Benötigt man für jedes Feld einer JSF-Seite wirklich ein weitgehend sinnfreies Getter/Setter-Paar in der zugehörigen Managed-Bean ?
Nein - denn JSF ist konfigurierbar und Java bietet das Reflection-Package...

In der faces.config.xml kann der zu verwendende ELResolver geändert werden:

<application>  
  <el-resolver>
     com.whatever.package.FieldResolver
  </el-resolver>     
</application>

Die Methoden des EL-Resolvers werden dann analog dem folgenden Beispiel für getValue implementiert.
Zuerst wird weiterhin versucht, einen passenden Getter zu finden. Das ist wichtig, um Sonderfälle, die ohne Getter nicht auskommen, behandeln zu können. Wurde keine Methode gefunden, wird nach einem entsprechenden Class-Field gesucht. Nur bei letztendlichem Erfolg wird die Anfrage als bearbeitet markiert (context.setPropertyResolved(true)) - andernfalls werden implizit die übrigen EL-Resolver aufgerufen.
Da dies alles nur Sinn macht, wenn es überhaupt um Objekt-Properties geht, werden nur Ausdrücke mit einem Basis-Objekt bearbeitet (base != null).


public class FieldResolver extends ELResolver {
    private static final Object[] sNoArgs = new Object[0];
    private static final Class[] sNoClassArgs = new Class[0];

    public Object getValue(ELContext context, Object base, Object property) throws NullPointerException, PropertyNotFoundException, ELException {
        String name = property.toString();

        if (base != null) {
            // 1. try getter
            try {
                String getterName = "get" + name.substring(0, 1).toUpperCase() + name.substring(1);
                Method getter = base.getClass().getMethod(getterName, sNoClassArgs);
                context.setPropertyResolved(true);
                return getter.invoke(base, sNoArgs);
            }
            catch (NoSuchMethodException ne) {
                // no error so far           
            }
            catch (Exception ex) {
                throw new RuntimeException(ex);
            }

            // 2. direct field access
            try {
                Field field = getField(base, property);
                if (field != null) {
                    context.setPropertyResolved(true);
                    return field.get(base);
                }
            }
            catch (Exception e) {
                String message = "Error accessing property '" + name + "' in bean of type " + base.getClass().getName();
                throw new PropertyNotFoundException(message, e);
            }
        }

        return null;
    }
...
}

JSF und die Frage wie es losgeht

2008-03-22T19:13:00.006+01:00

Wer sich erstmals mit den Java Server Faces befasst und/oder von Struts umsteigt, steht wahrscheinlich vor der Frage, wie und wann man am besten einen UI-Controller bzw. die zugrundeliegende(n) Managed Beans initialisiert, sprich, die benötigten Daten lädt. Denn alle darzustellenden Felder werden nur lose an beliebige Beans gebunden. Abgesehen von weiterführenden Themen wie Servlet Filtern oder Phase Listenern gibt es keine vordefinierten Einsprungmethoden.
Eine simple Lösung macht sich die Möglichkeit der Expression Language (EL) zunutze, komplexere und hierarchische Property-Ausdrücke aufzulösen.

Anstatt beispielsweise den Kundennamen wie folgt zu binden,


<h:inputText
    id="name" value="#{customerController.name}">
</h:inputText>

setzt man ein Formbean-Object davor:


<h:inputText
    id="name" value="#{customerController.formBean.name}">
</h:inputText>

Die Formbean wird als normale Java-Bean implementiert:


public class CustomerBean {
   private String name;

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

   public String getName() {
      return name;
   }
}

Der Übersichtlichkeit kommt dies natürlich auch zugute, da der UI-Controller nicht mehr mit Gettern und Settern für alle Felder überschwemmt wird.

Im Controller gibt es nun eine zentrale Stelle für die Initialisierung:


public class CustomerController {
   public Object getFormBean() {
      if (formBean == null) {
         formBean = new CustomerBean();    
      
       // load form data, set form properties, etc.
       ... 
      }
   
      return formBean; 
   }  
   
   private CustomerBean formBean; 
}

Sobald erstmalig der Wert eines Feldes angefordert wird, wird die Formbean erzeugt - bei allen folgenden Property-Zugriffen wird die Initialisierung dann übersprungen.

JavaDB in 5 Schritten

2008-03-20T16:18:00.006+01:00

Für einen ersten Test mit der JavaDB (früher Apache Derby, davor IBM sowie Cloudscape) habe ich ein bestehendes Oracle/Postgres-Schema mit etwa 60 Tabellen übertragen.
Das ging erfreulich unkompliziert. Ebenso der anschließende Zugriff über Hibernate.
Angepasst werden mussten lediglich:

die ID-Vergabe aus Hibernate (statt Sequenzen nun Identity-Felder, durch Ableiten der SQL-Dialekte kann weiterhin mit bestehenden Entity-Annotations gearbeitet werden).
die JavaDB mag in Scripten keine NULL-Keywords hinter den Columns (NOT NULL fkt. selbstverständlich)

1. Der Server kann durch die mitgelieferten Batchdateien gestartet werden. Das Setzen der Umgebungsvariablen DERBY_HOME ist gar nicht nötig.
Im Falle von Windows:
startNetworkServer.bat im Verzeichnis javadb\bin

2. Anlegen einer Datenbank mit dem Kommandozeilentool "ij":
connect 'jdbc:derby://localhost:1527/c:/JavaDB/db/myDB;create=true';

3. Beispiel zum Ausführen eines Scripts über ij:
run 'c:\JavaDB\createDatabase.sql';

4. JDBC-Connections
Der Treiber für den Client/Server-Betrieb ist org.apache.derby.jdbc.ClientDriver, für den Embedded-Mode org.apache.derby.jdbc.EmbeddedDriver.
Für User + Passwort interessiert sich die JavaDB offenbar erst nach entsprechender Konfiguration.

5. Shutdown
Im Embedded-Mode erfolgt ein ordnungsgemäßes Herunterfahren durch Anfordern einer Connection:
DriverManager.getConnection("jdbc:derby:;shutdown=true");
Eigentümlicherweise bedankt sich die JavaDB dabei standardmäßig mit einer Exception (Error-Code 50000).

Weiteres:

Für den Embedded-Mode ist die Datenbank sofort nach Anfordern einer Connection über den DriverManager betriebsbereit.
Ohne weitere Änderungen werden nur lokale Verbindungen akzeptiert. Dies kann durch Ergänzen der Batchdatei mit folgendem Startparameter geändert werden:
(... ) org.apache.derby.drda.NetworkServerControl start -h 0.0.0.0
In URLs für den Embedded-Treiber entfällt die Host-Angabe (z.B.: jdbc:derby:c:/JavaDB/db/myDB)
Hilfestellung gibt ij durch das help-Kommando

Schließlich zur interessanten Frage: was ist mit der Performance ?
Nun, der Mythos von der Langsamkeit von Java wird mit einer in Java geschriebenen Datenbank sicherlich auch nicht aussterben.
Wie auch immer, der erste Eindruck ist gut (einige Suchanfragen über 10000 Artikelsätze mit Joins und Subselects).
Besonders interessant ist auf jeden Fall der Embedded-Mode für unkomplizierte Auslieferungen als Teil von Datenbank-Anwendungen oder für einen autarken JUnit-Testbetrieb.