English Version

Durch Verwendung von Technologien wie Enterprise Java Beans (EJB) und Enterprise Service Bus (ESB) ist es heute ohne Weiteres möglich, lose gekoppelte und feingranular modulare Dienste zu entwerfen, die in Kollaboration eine verteilte Anwendung ausmachen. Einheiten des Entwurfs sind nicht mehr ganze Anwendungen, sondern klar abgegrenzte Dienste, die lokal oder entfernt benutzt werden können. Diese Dienste werden auf ein oder mehreren Applikationsservern (AS) deployed und können dort benutzt werden. Wenn die Dienste selbst auf Funktionen aus Bibliotheken zugreifen müssen, so kann es passieren, dass zwei unterschiedliche Dienste dieselbe Bibliothek in unterschiedlichen Versionen verwenden (müssen). Da beim Standard-Deployment allerdings alles von einem Classloader geladen und instanziert wird, tritt das Problem auf, dass nicht genau vorherzusagen ist, welche der beiden Versionen ein und derselben Bibliothek zuerst geladen wird. Darüberhinaus ist es ja gerade notwendig beide Versionen vorzuhalten, da sie in unterschiedlichen Contexten verwendet werden. Dies ist ohne weiteres Zutun nicht möglich. Daher bietet der JBOSS AS die Möglichkeit, Einheiten des Deployments (EJBs oder ESBs) so zu konfigurieren, dass sie von einem isolierten Classloader geladen werden. Damit ist es möglich die gleiche Bibliothek mehrfach zu laden (insbesondere mit unterschiedlichen Versionen), wenn dies gewünscht wird.

Eine Beispielkonfiguration für ESBs ist im Folgenden dargestellt:

[deployment.xml]
<jbossesb-deployment>
	<loader-repository>
		fauorg.esb.loader:loader=simple-scoped
		<loader-repository-config>java2ParentDelegaton=false</loader-repository-config>
	</loader-repository>
</jbossesb-deployment>

Die Datei sollte deployment.xml heißen und unter src/main/resources/META-INF abgelegt werden. Sie sorgt dafür, dass Klassen in folgender Reihenfolge geladen werden:

1. /lib/ (aus dem verpackten ESBs)
2. server/default/lib/

Dabei werden also lediglich Klassen aus dem server/default/lib/ Verzeichnis geladen, die nicht mit verpackt wurden. Der Name des JMX Classloader Objekts ist im Beispiel fauorg.esb.loader und sollte vom Entwickler festgelegt werden. Damit lassen sich auch mehrere Einheiten des Deployments in einem Classloader zusammenfassen.

Nähere Informationen hierzu finden sich hier. Eine Zusammenstellung von UseCases zum Thema isoliertes Classloading auf dem JBOSS AS gibts hier. Zum Aktivieren eines Loggers für den Classloader verfolgt man am besten diese Anleitung.

Isolated loading of classes on JBOSS AS

Using techology like Enterprise Java Beans (EJB) and Enterprise Service Bus (ESB), it is easily possible to design granular, losely connected modular services. In collaboration, these create distributed applications. Design units are no longer complete applications, but clearly separated services that can be used locally or remotely. These services are deployed on one ore more application servers (AS), and can be used there. If the services themselves need to access libraries, it is possible for two different services to use the same library in different versions. Since in standard deployment, everything is loaded and instanced by a classloader, the problem can occur that it becomes impossible to predict which library will be loaded first. It is furthermore necessary to keep both versions available, since they are used in different contexts. Without additional information, that is not possible. That is why JBOSS AS offers the possibility of configuring deployment units (EJBs or ESBs) in such a way that they are loaded by an isolated classloader. That makes it possible to load the same library multiple times (especially in different versions) if that is necessary.

Here is an exemplary configuration for ESBs:

[deployment.xml]
<jbossesb-deployment>
	<loader-repository>
		fauorg.esb.loader:loader=simple-scoped
		<loader-repository-config>java2ParentDelegaton=false</loader-repository-config>
	</loader-repository>
</jbossesb-deployment>

The file should be named deployment.xml and put in src/main/resources/META-INF. It ensures that classes are loaded in the following order:

1. /lib/ (from the packaged ESBs)
2. server/default/lib/

That means that only classes from the directory server/default/lib/ that weren’t packaged are loaded. The name of the JMX Classloader Object can be found in example fauorg.esb.loader and should be defined by the developer. This allows for several deployment units to be combined into one classloader

You can find further information here. A summary of UseCases regarding isolated classloading on the JBOSS AS can be found here. To activate logging for the classloader, follow these instructions.

English Version

Wenn Hibernate so konfiguriert ist, dass es das relationale Schema der Datenbank selbst erzeugt, werden alle Tabellen- und Spaltennamen derart erzeugt, dass sie lediglich aus Kleinbuchstaben bestehen. Das ist meines Erachtens auch sinnvoll, weil durch die Verwendung von Hibernate das zugrundeliegende Datenbankmanagementsystem einfach ausgetauscht werden kann. Einige Datenbanksysteme sind jedoch case-sensitiv und würden bei Verwendung einer ‘beliebigen’ Schreibweise Fehler erzeugen. Verfolgt man daher die Konvention alles klein zu schreiben, entstehen diese Probleme gar nicht. Des Weiteren ist es nicht empfehlenswert Tabellen- oder Spaltennamen zu vergeben, die sich einzig durch ihre Verwendung von Groß- und Kleinbuchstaben unterscheiden. Über die bessere Lesbarkeit von Tabellen- oder Spaltennamen mit gemischter Schreibweise (beispielsweise durch Verwendung von Binnenmajuskeln) lässt sich ohnehin streiten.

Hat sich ein Datenbankadministrator dennoch dafür entschieden Großbuchstaben in Bezeichnern eines relationalen Schemas zu verwenden, oder liegt das Datenbankschema schlicht bereits vor, wenn Klassen auf Relationen gemappt werden, kommt man nicht umher den Namen des Feldes oder der Tabelle explizit zu definieren. Ohne diese Definition würde Hibernate die Namen der Membervariablen und Klassen vollständig klein geschrieben verwenden und Datenbanksysteme, die Groß- und Kleinschreibung unterscheiden, würden Fehler erzeugen. Um den Namen des Bezeichners für die Datenbank zu definieren muss man lediglich den name-Parameter der Annotationen @Table und @Column (beide aus javax.persistence) verwenden und den vergebenen Namen in Backticks (`) setzen:

@Entity
@Table(name="`MyEntity`")
public class MyEntity {

  @Column(name="`StartDatum`")
  protected Date startDatum;

  ...
}

Das Mapping verwendet also eine Tabelle namens MyEntity, in der sich ein Feld namens StartDatum befindet.

Dank gilt Frank Tröger, der diesen Trick gefunden hat. Sollte man bei der Verwendung von Bezeichnern, die gleichzeitig Schlüsselwörter der Sprache SQL sind, Probleme haben, könnte die Verwendung von eckigen Klammern helfen.

Hibernate and case sensitive table and column names

If Hibernate is configured to create the relational database schema itself, all table and column names created will be lower case. I think this is reasonable in most cases, as you can simply switch the underlying database management system when using Hibernate. Several database systems are case sensitive, however, and would generate errors when using an ‘arbitrary’ notation. If you keep to the standard of writing everything lowercase, these problems won’t turn up. It is also not advisable to chose table or column names that only differ in their use of lower or uppercase letters. Whether or not table and column names with mixed notation (e.g. when using Camel Case) are better to read is open to discussion, anyway.

If the database admin decided to use upper case characters in relational schema names, or when the database schema is already existent when classes are mapped to relations, you won’t get around an explicit definition of fields or tables. Without this definition, Hibernate will use lower case for all member variables and classes, causing database system that differentiate between lower and uppercase to generate errors. To create a definition for a designator, simply use the name parameter of annotations @Table and @Column (both from javax.persistence) and put the name in backticks (`):

@Entity
@Table(name="`MyEntity`")
public class MyEntity {

  @Column(name="`StartDatum`")
  protected Date startDatum;

  ...
}

Mapping thus uses a table called MyEntity, with a field called StartDatum.

Thanks go to Frank Tröger, who found this trick. If you have problems using designators that are SQL key words, the use of square brackets might help.

Farbcodiertes Logging für JBoss und JBoss ESB

English Version

Sowohl während der Entwicklung als auch in einer Produktivumgebung können nach Prioritäten farbcodierte Logs sehr nützlich sein. Die folgenden Logging Konfiguration werden auf den von PP genutzten JBoss und JBoss ESB Systemen verwendet.

1. Die Konfiguration des JBoss Loggings ist in der Datei $JBOSS_HOME/server/default/conf/jboss-log4j.xml definiert. Der Standard ConsoleAppender kann durch den ANSIConsoleAppender ersetzt werden. Die Declaration sieht folgendermaßen aus:

   <!--<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">-->
   <appender name="CONSOLE" class="de.rrze.ppsa.log.ANSIConsoleAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="Target" value="System.out"/>
      <param name="Threshold" value="INFO"/>
 
      <layout class="org.apache.log4j.PatternLayout">
         <!-- The default pattern: Date Priority [Category] Message\n -->
         <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
      </layout>
   </appender>

Um ähnliche Farbcodierungen für den server.log zu erhalten, der ein anderes Farbschema benutzt, müssen die folgenden Änderungen vorgenommen werden:

   <!-- A time/date based rolling appender -->
   <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="File" value="${jboss.server.log.dir}/server.log"/>
      <param name="Append" value="false"/>
 
      <!-- Rollover at midnight each day -->
      <param name="DatePattern" value="'.'yyyy-MM-dd"/>
 
      <!-- Rollover at the top of each hour
      <param name="DatePattern" value="'.'yyyy-MM-dd-HH"/>
      -->
 
      <layout class="org.osuosl.logging.ANSIColorLayout">
         <!-- The default pattern: Date Priority [Category] Message\n -->
         <param name="ConversionPattern" value="%d %-5p [%c{1}] %m%n"/>
 
         <!-- The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n
         <param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
          -->
      </layout>
   </appender>

2. Zuletzt muss ppsa-log4j-color-0.0.1.jar zum JBoss classpath hinzugefügt werden. Dies wird dadurch erreicht, dass man es in die $JBOSS_HOME/server/default/lib kopiert. Die Jar-Datei enthält sowohl den ANSIConsoleAppender als auch die ANSIColorLayout Klassen.
3. Nicht vergessen, den Server danach neu zu starten.

Die vorgeschlagene Lösung basiert auf dem ANSIColorAppender, geschrieben von Dan Dyer und dem ANSIColorLayout von Peter Krenesky.

During development cycle or in a productive environment color-coded log messages based on their priority can prove pretty useful. The following logging configurations are deployed on the JBoss and JBoss ESB systems used by PP:

1. The JBoss loggin configuration is defined in the $JBOSS_HOME/server/default/conf/jboss-log4j.xml file. The standard ConsoleAppender can be exchanged with the ANSIConsoleAppender. Declaration change looks like that:

   <!--<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">-->
   <appender name="CONSOLE" class="de.rrze.ppsa.log.ANSIConsoleAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="Target" value="System.out"/>
      <param name="Threshold" value="INFO"/>
 
      <layout class="org.apache.log4j.PatternLayout">
         <!-- The default pattern: Date Priority [Category] Message\n -->
         <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
      </layout>
   </appender>

in order to get similar color-coding(this one uses different color scheme) for the server.log the following changes have to applied:

   <!-- A time/date based rolling appender -->
   <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="File" value="${jboss.server.log.dir}/server.log"/>
      <param name="Append" value="false"/>
 
      <!-- Rollover at midnight each day -->
      <param name="DatePattern" value="'.'yyyy-MM-dd"/>
 
      <!-- Rollover at the top of each hour
      <param name="DatePattern" value="'.'yyyy-MM-dd-HH"/>
      -->
 
      <layout class="org.osuosl.logging.ANSIColorLayout">
         <!-- The default pattern: Date Priority [Category] Message\n -->
         <param name="ConversionPattern" value="%d %-5p [%c{1}] %m%n"/>
 
         <!-- The full pattern: Date MS Priority [Category] (Thread:NDC) Message\n
         <param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%x) %m%n"/>
          -->
      </layout>
   </appender>

2. At last the ppsa-log4j-color-0.0.1.jar has to be added to the JBoss classpath. This can be achieved by copying it in the$JBOSS_HOME/server/default/lib. This jar file contains the ANSIConsoleAppender and the ANSIColorLayout classes.
3. Do not forget to restart the server.

The proposed solution is based on the ANSIColorAppender written by Dan Dyer and the ANSIColorLayout provided by Peter Krenesky.

Während ich am FAU.ORG Projekt arbeitete, stellte ich fest, dass viele verschiedene Webkomponenten von der bereits existierenden alpha Version der WAID Applikation in dem zurzeit entwickelnden fauorg-web Teilprojekt übernommen werden müssen(für mehr Information wenden sie sich bitte an das FAU.ORG Blog). WAID ist die Web Oberfläche des IDMone Projektes und funktioniert als self-service Portal für die an der Friedrich-Alexander Universität Erlangen-Nürnberg beschäftigten Personen. Das ausgewählte Webframework für beide Anwendungen ist Tapestry 5 und es ist als ein Teil des PPSA Apllikationsstacks definiert.

Im Vergleich mit anderen Java Webframeworks bietet Tapestry eine komponentenbasierte Platform, die die Wiederverwendung des existierenden Kodes ermöglicht. Mehrere Instanzen von den vorgegebenen Komponenten können innerhalb einer Applikation eingebaut werden. Die Komponenten können auch in einzelnen Modulen extrahiert werden, die später als Bausteine verwendet werden können. Es wurde die Entscheidung getroffen, von der oben erwähnten Modularität Gebrauch zu machen, deswegen wurden manche Komponenten von WAID entfernt und in einzelnen Projekte übertragen. Zurzeit sind die folgenden Module in PPSA verfügbar:

• ppsa-t5-commons
• ppsa-t5-d7
• ppsa-t5-jcaptcha
• ppsa-t5-weather

Das wichtigste von den oben erwähnten Projekten ist ppsa-t5-commons. Dieses Projekt definiert die Platform aller Webapplikationen, die mithilfe von PPSA entwickelt wurden, weil es die Tapestry 5 Libraries beinhaltet. Auf dieser Art und Weise wird die Konsistenz innerhalb der verschiedenen Anwendungen so wie die in denen implementierten Komponenten bewahrt. Der ausgewählte Ansatz setzt die Libraryversionen fest, die von der Platform verwendet sind, und sichert die Verbreitung einer vereinheitlichten Entwicklungsbasis ab. Alle weiteren Projektkomponenten sollten das ppsa-t5-commons als Abhängigkeit beinhalten, so dass die mit der Architektur übereinstimmen. Dadurch ist im Fall einer Änderung von der Tapestry- oder Apache commons-logging- Version eine einzige Aktualisierungsschittstelle definiert.

Ppsa-t5-commons trägt nicht nur dazu bei die Platform zu definieren, sondern auch
oft genutzte Tapestry Komponenten. Aktuell sind es:

• AlternatingClass – eine Komponente, die ungerade und gerade Tabellenzeilen rendert
• FileUpload – eine Komponente, die auf Apache commons-upload basiert und Dateien hochladet
• SwitchLocale – eine Komponente, die das ?Locale? innerhalb der Webapplikation verändert
• FlotrGraph – eine Komponente, die Browser basierte Diagramme rendert, Flotr Library nutzt und die Serverauslastung reduziert
• GoodiesTree – eine Baumkomponente, die auf XHTML Goodies basiert
• JQueryTree – eine Baumkomponente, die auf JQuery Script Libraries basiert
• TafelTree – eine Baumkomponente, die auf TafelTree Prototype Library basiert
• ProgressBar – eine Progressbarkomponente , die auf die Prototype-basierende Livepipe Library beruht
• ULAutoUpdate – ein Mixin, das die Prototype Javascript Library verwendet um eine Komponente periodisch zu aktualisieren

Das ppsa-t5-d7 Modul beinhaltet alle Seiten, Komponenten, CSS Dateien, Javascript Dateien, Bilder usw., die zu dem D7 Design des RRZE Vorlagenkatalogs gehören. Dieses Modul definiert eine Tapestry Layout Komponente, die auf verschiedenen Seiten benutzt werden kann um das Corporate Design zu wahren. Das Modul beschäftigt sich auch mit der Sessionverwaltung so wie: An- und Abmeldung, Zeitablauf usw. Die Aufgabe des ppsa-t5-jcaptcha Modules ist die Gewährleistung einer wiederverwendbaren JCaptcha Komponente und des entsprechenden Tapestry Services. Trotz nicht anerkannter Barrierefreiheit sollten diese vor Hackerangriffe schützen. Das letzte ppsa-t5-weather Modul ruft die Wettervorhersage von Yahoo!’s Feed ab und wandelt sie in reinen HTML Kode um.

Eine Dokumentation und Beispiele, wie man die verschiedenen Module und Komponenten benutzt, werden bald auf der PPSA Wiki Seite verfügbar sein. Manche Beispiele werden auch auf dieser Seite geblogt.

PPSA T5 Components

While I was working on the FAU.ORG project, I identified that various web components had to be migrated from the existing alpha version of the WAID web application into the currently developed fauorg-web subproject(see the FAU.ORG for more information). WAID is the web front-end of the IDMone project and functions as a self-service portal for people associated with Friedrich-Alexander University Erlangen-Nürnberg. The web framework of choice for both application is Tapestry 5 and is defined as a part of the PPSA application stack.

Compared with other Java web frameworks, Tapestry provides a component based platform which allows for re-usability of existing pieces of code. Multiple instances of a given component can be embedded within an application. Components can also be extracted into separate modules which can be later used as building blocks. A decision was made to take advantage of the above mentioned modularity and several important components were taken out from WAID and moved into individual projects. Currently the following modules are available under the PPSA initiative:

• ppsa-t5-commons
• ppsa-t5-d7
• ppsa-t5-jcaptcha
• ppsa-t5-weather

The most important of the above listed projects is the ppsa-t5-commons. This project defines the platform of all web applications developed under PPSA as the Tapestry 5 libraries are included in it. This provides consistency within the different applications and the components implemented as parts of them. The chosen approach fixes the version of the libraries used by the platform and ensures propagation of a unified development base. All other component projects should include ppsa-t5-commons as a dependency to conform with the architecture. Thus a single point of update is defined in case of a change of the Tapestry or of the Apache’s commons-logging version.

ppsa-t5-commons not only defines the platform but also contributes some commonly used Tapestry components. At the moment of writing these are:

• AlternatingClass – a component used to render odd and even table rows
• FileUpload – a component used for file uploads, based on Apache commons-upload
• SwitchLocale – a component which changes the locale within the web application
• FlotrGraph – a component for browser graph rendering, uses Flotr alpha library, reduces server load
• GoodiesTree – a tree component based on XHTML Goodies
• JQueryTree – a tree component based on the JQuery script libraries
• TafelTree – a tree component based on the TafelTree Prototype library extension
• ProgressBar – a progress bar component using the Prototype-based Livepipe library
• ULAutoUpdate – a mixin which uses the Prototype javascript library to periodically update a component

The ppsa-t5-d7 module provides all the pages, components, CSS files, javascript files, images and so on that belong to the D7 design from the RRZE’s Vorlagenkatalog. The module defines a Tapestry layout component that can be used within different pages to ensure corporate design. The module also handles basic session management such as – login, logout, timeout and so on. The role of the ppsa-t5-jcapcha module is to provide a reusable JCaptcha component and a corresponding Tapestry service. These should be used to protect from intruder attacks, though are not generally considered appropriate for disabled users. The last module – ppsa-t5-weather, is a modules which fetches the weather forecast from Yahoo!’s feed and renders it as HTML code.

Documentation and examples of how to use the different modules and components will soon be available on the PPSA wiki page. Some samples will be also posted in this blog.

PPSA?!

Um die Anforderungen einer standardisierten Software Entwicklung am RRZE zu erfüllen, müssen Vorgaben, Regeln, Techniken und Werkzeuge formuliert werden.
Dies ist innerhalb von P&P die Aufgabe von PPSA. Eine Software-Architektur und ein Anwendungsumgebung müssen definiert, zusammengestellt und getestet werden, um eine gemeinsame Basis für die Entwicklung zukünftiger Produkte zu schaffen und agile Prozesse zu ermöglichen. Die Anwendungsumgebung hat das Ziel einen Rahmen zu bilden der benötigte Funktionen vor allem via Web zur Verfügung stellt. Hierbei legen wir besonders Wert auf barrierefreie Anwendungen.

Desweiteren ist es die Aufgabe von PPSA qualitätsgesicherte Komponenten und Code zur Verfügung zu stellen die flexibel wieder verwendet oder in andere Produkte eingebunden werden können. Dies erfolgt meistens in Form öffentlicher Open-Source-Projekte.

Verantwortlich für PPSA zeichnen der Chief Software Architect (CSA) Krasimir Zhelev und sein Stellvertreter Frank Tröger.

Für Mitarbeiter der RRZE stehen die relevanten Informationen im PP-Wiki. Externe wenden sich bitte direkt an Herrn Zhelev.

PPSA?!

To meet the requirement for standardizing the software development at RRZE, a definition of well-established rules, policies, techniques and tools has to be enforced. This is the main objective of PPSA within P&P. A software architecture and an application stack has to be defined, assembled and tested to provide common development basis for future products and accommodate Agile processes. The software stack aims at building up a framework for exposing needed functionality through web interfaces. Here we should mention that accessibility is of major importance for us.

A further task of PPSA is to develop quality-assured components and code packages that can be flexibly reused or embedded in other products. These artifacts are mostly published as open source projects.

Responsible for PPSA is Chief Software Architect (CSA) Krasimir Zhelev and his deputy Frank Tröger.

For RRZE members, the relevant information can be accessed via PP-Wiki. Non-members are to contact Mr. Zhelev, please.