Visual Basic Editor

Programmieren tut man im mitgelieferten Visual Basic Editor (VBE). Der VBE lässt sich über die Tastenkombination ALT+F11 oder aus dem Entwicklungstab des Ribbon starten. Wie das Entwicklungstab eingeblendet wird hatten wir im letzten Artikel besprochen.

Der Funktionsumfang von VBE ist eher rudimentär. Besserung gibt es in Form des Addons MZTools. Dieses liefert viele vermisste Funktionen nach und ist zudem kostenfrei erhältlich. Wichtig: die Version 3.0 wählen.

Eine Funktion die VBE bietet, die man aber wegen ihres aufdringlichen Verhaltens besser abschaltet ist die automatische Fehlerprüfung nach Abschluss eine Zeile. Verlässt man eine Zeile, die ungewollt oder absichtlich noch Fehler enthält, wird man umgehend mit einer Fehlermeldung in Form eines Hinweisfensters bestraft. Diese Funktion kann man getrost abschalten, fehlerhafte Zeilen werden immer noch deutlich sichtbar in rot dargestellt, jedoch wird der Arbeitsfluss nicht mehr unterbrochen.

Teamarbeit

Plant man mit mehreren Leuten im Team zu arbeiten, wird man schnell feststellen, dass das so nicht vorgesehen ist. VBE unsterstützt grundsätzlich nur eine Person. Muss man trotzdem mit mehreren Personen an einem Projekt arbeiten, kann man dies mithilfe eines Versionskontrollsystems wie Subversion versuchen. Ich schreibe versuchen, weil auch diese Art des Arbeitens (bzw. Versionskontrollsysteme allgemein) von VBE nicht unterstützt wird. So kann man zwar Exceldateien unter Versionskontrolle stellen, jedoch können diese mit dem Format nichts anfangen und Änderungen von mehreren Personen auch nicht zusammenführen. Man muss die einzelnen Module und Klassen aus VBE heraus ex- und importieren und das Versionskontrollsystem manuell steuern (etwa über TotoiseSVN für Subversion). Das ist aber auf Dauer ein mühseliges und sehr fehleranfälliges Verfahren.

Ein weiteres Addin für den VBE kann hier zumindest Unterstützung anbieten. Mit CodeCleaner kann man den Ex- und Import der Module automatisieren. Das Versionskontrollsystem muss man aber nach wie vor selbst bedienen.

Der Vollständigkeit halber sei erwähnt, dass es auch ein Addin gibt, das auf Teilen von CodeCleaner aufsetzt und auch den SVN Im- und Export übernimmt. Dieses Addin ist aber einerseits auf Subversion ausgelegt und hat bei mir im Praxiseinsatz nicht überzeugt. Aber beide Addins sind kostenlos und im Quellcode verfügbar, so dass mit etwas VBA-Kenntnissen und Zeit jeder eine eigene Lösung entwickeln kann.

Struktur und Art

Exceldateien unterscheiden sich in solche Mit Codemodulen (*.xlsm) und solche Ohne Codemodule (*.xlsx) und Addins (*.xlam). Addins besitzen keine für den Benutzer sichtbaren Tabellen, diese sind allerdings vorhanden und verwendbar, lassen sich nur nicht für den Benutzer darstellen.

Eine Exceldatei besteht aus:

• Excel-Objekten
• Arbeitsmappe
• Tabellen
• Formulare
• Module
• Klassenmodule

Code lässt sich in allen Teilen ablegen. Der beste Ort hängt von der Art des Problems und der Form des zu entwickelnden Programms ab.

Grob kann man sagen: Arbeitsmappen/Tabellenspezifischer Code wird im entsprechenden Excel-Objekt abgelegt, GUI-Beschreibungen (mit grafischem Editor) und zugehöriger Code als Formulare. Der Großteil des Codes (insbesondere bei Addins) dürfte jedoch in Modulen hinterlegt werden und bei objektorientierter Programmierung in Klassenmodulen.

Addins

Addins dienen dazu Excel um neue Funktionen zu erweitern. Man kann neue Tabellenfunktionen entwickeln, neue Benutzeroberflächen inklusive Ribbon-Einbindung. Es lässt sich auf beinahe jedes Ereignis von Excel reagieren und wenn man will kann man auch komplett die Kontrolle übernehmen und Excel wie seine eigene Anwendung aussehen lassen.

Bei der ersten Eigenschaft „Typ“ wird ausgesagt welche Interfaces implementiert werden. Damit werden Aussagen darüber gemacht welche Zugriffsmöglichkeiten auf die Elemente möglich sind. Der Typ mit den wenigsten Möglichkeiten ist Set. Hier sind nur Basisoperationen wie add, remove und contains vorhanden. Eine List bietet zudem noch die Möglichkeit, per Indizes Elemente hinzuzufügen, zu löschen oder auszulesen. Methoden wie push und pop, die Zugriff auf die Elemente in einer FIFO-Manier gewähren, sind für den Typ „Stack“ gegeben. Queues bieten die Methoden add/offer, remove/poll sowie element/peek an, um auf die Elemente in Form einer Warteschlange zuzugreifen. Beim Typ Map handelt es sich eigentlich um keine echte Collection. Das Collection-Interface wird zwar tatsächlich nicht implementiert, dennoch werden auch Maps zum Speichern vieler Elemente, also als Collection, genutzt. Der größte Unterschied zu den restlichen Collections ist, dass aufgrund dieser Tatsache kein Iterator zum Durchlaufen der Elemente erzeugt werden kann. Der Zugriff wird stattdessen über die Methoden keySet, values und entrySet (die drei sog. „Views“) realisiert.

Des weiteren fällt auf, dass viele der Collections nicht thread-safe sind. Dieses Problem lässt sich relativ einfach mit der Utility-Klasse Collections lösen. Diese bietet zum Beispiel für Maps die statische Methode

Map Collections.synchronizedMap(Map map)

an, die eine Map zurückliefert, die die selben Elemente enthält, deren Methoden aber synchronized sind. Bemerkenswert ist dabei auch, dass diese Methode auch für den Typ Map existiert, obwohl es sich bei dieser um keine Collection handelt.

Außerdem hat prinzipiell auch jede Klasse die Möglichkeit mit null-Werten umgehen zu können. Hierfür muss lediglich bei der Erzeugung der Collection ein passender Comparator übergeben werden, der in der Lage ist, auch null-Werte zu sortieren. Dieses Problem besteht nämlich ausschließlich bei den Implementierungen, die die Elemente mittels einem Comparator sortieren müssen.

Zu guter Letzt ist es wichtig zu wissen, dass die verschiedenen Implementierungen unterschiedlich schnell sind. Die Thread-sicheren Varianten sind normalerweise immer langsamer als ihre nicht-synchronisierten Alternativen. Aber auch mögliche Tuningparameter wie beispielsweise initial-capacity oder load-factor sollten sinnvollerweise an den konkreten Fall angepasst werden. Für welche Implementierung man sich letztlich entscheidet muss von der häufigsten Verwendungsart abhängig gemacht werden. Zum Beispiel ist eine ArrayList beim Zugriff auf ein indiziertes Element schneller als eine LinkedList. Die LinkedList ist dafür beim Einfügen neuer Elemente performanter. Da diese Implementierungsdetails allerdings über diesen Überblick hinausgehen, ist dafür im konkreten Anwendungsfall die offizielle API zu konsultieren.

Hier die Übersichtstabelle:

Solution:
All you need is some maven plugins and a place to write the build number to.
In this case I’d like to have the maven version number followed by the subversion revision number and a timestamp of the build date like this:

Version: 1.0-SNAPSHOT r1 Built on: 2012-02-19 13:41

First I create a version.html in src/main/resources or src/main/templates or something like that:

<div class="version">Version: @VERSION@</div>
<div class="builton">Built on: @BUILTON@</div>

As you can see there are two placeholders (@VERSION@ and @BUILTON@)
Next I insert and configure the plugins to create the version info and the timestamp and to replace the placeholders with them in my pom.xml:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>maven-buildnumber-plugin</artifactId>
<executions>
<execution>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
</execution>
</executions>
<configuration>
<doCheck>true</doCheck>
<doUpdate>false</doUpdate>
</configuration>
</plugin>

This creates a property named buildNumber with the revision number of the checked out code. The configuration doCheck=true causes a check whether there are any uncommitted changes. If there were any, the build would fail. With doUpdate you could instruct the build to execute a svn update prior to execution of the build.
For more info about this plugin see here:
http://mojo.codehaus.org/buildnumber-maven-plugin/
We could also use this plugins goal “create-timestamp” to create the timestamp, but since maven itself provides a property for that we just need to set that properties format in the properties section of our pom:

<properties>
<maven.build.timestamp.format>yyyy-MM-dd HH:mm</maven.build.timestamp.format>
</properties>

Now having all we need, we need to replace the placeholders in our html and copy the replacement to our target folder.

<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>maven-replacer-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<phase>prepare-package</phase>
<goals>
<goal>replace</goal>
</goals>
</execution>
</executions>
<configuration>
<file>src/main/templates/version.html</file>
<outputFile>target/version.html</outputFile>
<regex>false</regex>
<replacements>
<replacement>
<token>@VERSION@</token>
<value>${version} r${buildNumber}</value>
</replacement>
<replacement>
<token>@BUILTON@</token>
<value>${maven.build.timestamp}</value>
</replacement>
</replacements>
</configuration>
</plugin>

This replaces the placeholders in src/main/templates/version.html with the values and writes the result into the specified target folder.
More info about this plugin is provided here:
http://code.google.com/p/maven-replacer-plugin/
Having that, you just need to include that into your pages. That’s it.

Conclusion:
We now have a build number on our pages.
There for sure is room to improve this solution and it is for sure not the only solution. But it did the job for me and I hope it will help you.
If I should have forgotten something in this description, do not hesitate to give me feedback via the comments form.

Websphere 7 als Java-EE5-Applikationsserver bietet keine JSF-2.0-Implementierung
an – zu Zeiten von Java-EE5 war noch JSF 1.2 aktuell. Wie es denoch geht, will
ich hier zeigen.

Websphere 7 als Java-EE5-Applikationsserver bringt zwei JSF-1.2-Implementierungen
mit – eine (leicht modifizierte) Sun-Referenz-Implementierung und MyFaces. Wer
bereits mit JSF 2.0 gearbeitet hat, wird den Weg zurück nach JSF 1.2 sicher nicht
gehen wollen, deshalb habe ich hier die Schritte aufgeschrieben, die notwendig sind,
um Websphere 7 (und auch WS8!) JSF 2.0 mit Richfaces schmackhaft
zu machen.

Lösung

1. Die zu deployende WAR/EAR-Datei muss Mojarra 2.0.4 oder 2.0.8 (nicht 2.1.x,
nicht 2.0.2) enthalten.
In der Regel ist das eine jsf-api.jar und eine jsf-impl.jar (manchmal
auch eine einzelne Datei namens javax.faces-2.x.x.jar).
Diese JSF-Implementierung (Mojarra 2.0.4) kommt in das Verzeichnis WEB-INF/lib.

Wer Maven nutzt, kann folgende Dependency hinzufügen:

<dependency>
  <groupId>org.glassfish</groupId>
  <artifactId>javax.faces</artifactId>
  <version>2.0.4</version>
</dependency>

Neuere Versionen von JSF (2.1.+) benötigen die Servlet-API 3.0, die
normaler Weise nur bei JavaEE6-Servern zu finden ist.
Versucht man, andere Versionen als die JSF 2.0.4/2.0.8 zu nutzen, dann steigt
die Web-Anwendung mglw. mit folgender Fehlermeldung im Log aus:

javax.servlet.ServletException: SRVE0207E: Es wurde eine nicht abgefangene Initialisierungsausnahme vom Servlet erstellt.
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:434)
at com.ibm._jsp._index._jspService(_index.java:85)
Caused by: java.lang.IllegalStateException: Die Anwendung wurde bei Systemstart nicht einwandfrei initialisiert,
Factory konnte nicht gefunden werden: javax.faces.context.FacesContextFactory. Rügriff versucht.
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:270)

2. Die web.xml muss folgenden Eintrag enthalten, um JSF zu initialisieren:

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

Im Websphere-Log (%websphere%/profiles/AppSrv01/logs/server1/SystemOut.log) wird der Start
von JSF 2.0.4 mitgeloggt:

[29.01.12 01:36:08:000 CET] 0000001b config I
Mojarra 2.0.4 (FCS b09) für Kontext '/CompositeComp' wird initialisiert.

3. Der Websphere-Log beklagt sich über eine fehlende Zuweisung des Mime-Typs für xhtml,
für den Fall, dass Dateien mit der Endung .xhtml als JSF-Datei erkannt werden.
Dazu muss in der (applikationsbezogenen oder der allgemeinen) web.xml folgender
Eintrag hinzugefügt werden:

<mime-mapping>
  <extension>xhtml</extension>
  <mime-type>application/xhtml+xml</mime-type>
</mime-mapping>

4. Wir fügen unserem Projekt Richfaces hinzu.
Getting Started
Der Websphere-Log gibt jetzt u.a. folgende Warnung aus:

[29.01.12 01:36:10:015 CET] 0000001b Config W
org.richfaces.javascript.ClientServiceConfigParser parse Found JavaScript function definition
for class javax.validation.constraints.NotNull, but that class is not presented

Möchte man javascriptseitige Bean-Validierung (JSR330) nutzen, dann sind diese JAR-
Dateien noch nach WEB-INF/lib zu kopieren:
* validation-api.jar (version 1.0.0.GA)
* hibernate-validator.jar (version 4.2 or higher)
Siehe http://docs.jboss.org/richfaces/latest_4_1_X/
Developer_Guide/en-US/html/chap-Developer_Guide-Getting_started_with_RichFaces.html

Natürlich kann man sich diesen Schritt sparen, wenn nur serverseitig (und nicht per JS)
validiert wird.

Validation-API:

<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.0.0.GA</version>

Hibernate-Validator:

<artifactId>hibernate-validator-parent</artifactId>
<groupId>org.hibernate</groupId>
<version>4.2.0.Final</version>

5. Es wird allgemein empfohlen, eine “Gemeinsam genutzte isolierte Bibliothek” anzulegen,
falls nicht die mit dem Websphere mitgelieferten JSF-Implementierungen (JSF1.2 und
MyFaces) genutzt werden, sondern externe.
In meinem Fall hat das nicht geklappt. Es ging nur dann, wenn ich meiner WAR-Datei die
JSF-Dateien hinzugefügt und den Listener in der web.xml eingestellt hatte.
So geht’s laut IBM:

JavaServer-Faces-Implementierung konfigurieren

6. Es wird immer noch der EL-Parser von IBM genommen, so dass die Auswertung von
Methoden-Parametern nicht möglich ist. Ein #{myBean.write(‘Hallo’)} führt folglich
zu einem Fehler.

org.apache.el.parser.ParseException: Encountered "(" at line 1, column 22.
Was expecting one of: "}" ... "." ... "[" ... ">"
at org.apache.el.parser.ELParser.generateParseException(ELParser.java:2142)

Wir müssen jetzt also auch den EL-Parser aktualisieren. Wie das geht,
wird dort beschrieben:

http://rueprich.de/bloggt/2010/06/expression-language-2-2-mit-maven-und-tomcat

<dependency>
  <groupId>javax.el</groupId>
  <artifactId>el-api</artifactId>
  <version>2.2</version>
</dependency>

<dependency>
  <groupId>org.glassfish.web</groupId>
  <artifactId>el-impl</artifactId>
  <version>2.2</version>
</dependency>

web.xml:

<context-param>
  <param-name>com.sun.faces.expressionFactory</param-name>
  <param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>

Im Websphere-Log erscheint folgende Warnung:

I JSF1027: [null Die ELResolvers für JSF wurden nicht im JSP-Container registriert.

Diese Meldung werde ich ignorieren, da ich jetzt dank JSF 2.0 kein JSP mehr verwenden muss.

7. Sich freuen über eine aktuelle JSF-2.0-Implementierung mit ebenso aktueller Expression
Language.

Was bringt die Akutalisierung auf JSF 2.0 für den Entwickler?

Ich will die aus meiner Sicht wichtigen Veränderungen an Minibeispielen kurz aufzeigen:
* ManagedBean und ManagedProperty via Annotation statt über XML-Dateien.
In JSF 1.2 sind ManagedBeans aufwändig zu konfigurieren. Neben der Java-Klasse
selbst hat man noch eine Menge XML-Konfiguration vor sich:
faces-config.xml:

<managed-bean>
  <managed-bean-name>carBean</managed-bean-name>
  <managed-bean-class>de.triona.view.CarBean</managed-bean-class>
  <managed-bean-scope>session</managed-bean-scope>
  <managed-property>
    <property-name>bikeBean</property-name>
  </managed-property>
</managedBean>
<managed-bean>
  <managed-bean-name>bikeBean</managed-bean-name>
  <managed-bean-class>de.triona.view.BikeBean</managed-bean-class>
  <managed-bean-scope>session</managed-bean-scope>
</managedBean>

In JSF 2.0 reduziert sich das auf eine Java-Klasse mit Annotationen:

@ManagedBean
@SessionScoped
public class CarBean {
  @ManagedProperty(value="bikeBean")
  BikeBean bikeBean;
}

* Direkte Navigation an Stelle der indirekten Navigation in faces-config.xml
* Die AJAX-Komponente f:ajax
Bsp.:

<h:inputText value="#{bean.text}">
  <f:ajax event="keyup" execute="@this" render="out"/>
</h:inputText>
<!-- Dieses Textfeld wird jetzt bei jedem KeyUp-Event neu gerendert-->
<h:outputText id="out" value="#{bean.text}"/>

Fazit

JSF 2.0 auf dem Websphere 7 ist mit einiger Mühe machbar.
Aber:Bei meinen Tests auf verschiedenen Rechnern gab es manchmal
Probleme und das Ende der Fahnenstange war doch das mitgelieferte JSF 1.2 -
je nach Patchversion des WS und der mitgelieferten Libraries der Anwendung.

Daher ist die Devise: ausprobieren!

Hat man in seinem System gleich mehrere solcher Anwendungsfälle ausfindig machen können, lohnt sich ein Blick auf Spring Batch [1]. Spring Batch ist ein sehr flexibles Framework für eben genau diese Batchverarbeitung von Daten. Es bietet eine simple Domainlanguage zur deklarativen Formulierung von Jobs und deren Steps, liefert fertige Zugriffsklassen für Datenbank- und Dateianbindung und Verwaltungs- und Monitoringfunktionen für die Jobs und deren ausführbare Instanzen. Das Einlesen einer kommagetrennten CSV-Datei, das Mapping der Spalten zu Attributen einer Fachklasse und das Schreiben der Fachklasse in wieder andere Spalten einer Datenbank ist somit ohne viel selbstgeschriebenen Code in kurzer Zeit erledigt. Weitere Details zu Spring Batch sind im genannten Link [1] zu finden, bzw. in den sehr zu empfehlenden Büchern [2] und [3].

Das einzige was Spring Batch von Haus aus nicht liefert, ist ein Scheduler zum zeitgesteuerten Ausführen der Batch-Jobs. Hier beruft man sich darauf, dass es am Markt etliche gute Scheduler gibt, die man in Spring Batch integrieren kann. Explizit genannt und zur Integration empfohlen sind der TaskScheduler aus dem Spring Framwork [4], oder der bekannte Quartz-Scheduler [5]. Aber auch andere Produkte (wie z.B. die EJB-Timer) lassen sich als Scheduler nutzen.

Spring Batch bietet auch hier fertige Klassen, die z.B. Quartz-Jobs nahtlos mit Batch-Jobs verknüpfen. Auch hier kommt man sehr schnell zu ersten lauffähigen Ergebnissen, wenn man statische Ausführungszeitpunkte zur Entwicklungszeit deklariert. Möchte man mehr Flexibilität, d.h. zur Laufzeit dynamisch Trigger zu Jobs verwalten, dann lohnt es sich, Quartz wieder etwas aus Spring Batch heraus zu lösen, um die komplette Kontrolle darüber zu bekommen.

Eine mögliche Vorgehensweise ist, lediglich die Batch-Jobs im Spring ApplicationContext zu deklarieren und die Quartz-Trigger selbst zu verwalten. Einziges Bindeglied zwischen Quartz und Spring-Batch ist dann ein generischer Quartz-Job, der beliebige Batch-Jobs startet. Im Folgenden wird das näher betrachtet.

<job id="csvImportJob">
    ...
</job>

Zuerst wird die gewünschte Funktionalität als Batch-Job implementiert. Dies ist nichts besonderes und losgelöst vom Scheduler.

<bean name="jobScheduler"
    class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
    <property name="applicationContextSchedulerContextKey"
             value="applicationContext" />
</bean>

Das Instantiieren eines Quarz-Schedulers übernimmt Spring Batch, was den Vorteil hat, dass im Context des Schedulers der ApplicationContext von Spring verfügbar ist. Nur dann können wir aus dem Quarz-Job heraus auf den Batch-Job zugreifen.

public final class JobStarter implements org.quartz.Job {
    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
        try {
            Scheduler jobScheduler = context.getScheduler();
            ApplicationContext appContext = (ApplicationContext) jobScheduler.getContext().get("applicationContext");
            JobLauncher jobLauncher = (JobLauncher) appContext.getBean(JobLauncher.class);
            JobRegistry jobRegistry = (JobRegistry) appContext.getBean(JobRegistry.class);
 
            JobDataMap jobDataMap = context.getJobDetail().getJobDataMap();
            Job job = jobRegistry.getJob(jobDataMap.getString("jobName"));
 
            jobLauncher.run(job, getJobParameters(jobDataMap));
        } catch (Exception exception) {
            // ...
        }
    }
 
    private static JobParameters getJobParameters(JobDataMap jobDataMap) {
        // Map Quartz-Job-Data to Batch-Job-Parameters
    }
}

Der generische Batch-JobStarter Quartz-Job. Dieser wird durch die definierten Trigger gestartet und die execute-Methode aufgerufen. Hier wird der Spring ApplicationContext geholt und daraus die nötigen Beans zur Batch-Job-Verwaltung. Den Namen des zu startenden Batch-Jobs, genauso wie dessen Batch-JobParameter, werden aus der Quartz-JobDataMap geladen und gemapped.

JobDetail jobDetail = new JobDetail("hourlyCsvImport", "defaultGroup", JobStarter.class);
jobDetail.getJobDataMap().put("jobName", "csvImportJob");
// Put additional Batch-JobParameter here
 
CronTrigger jobTrigger = new CronTrigger("hourlyTrigger", "defaultGroup", "0 0 0/1 * * ? *");
 
jobScheduler.scheduleJob(jobDetail, jobTrigger);

Zu guter letzt legen wir einen konkreten Quartz-Job an, der unseren Batch-JobStarter aufruft und den übergebenen Batch-Job startet. Für diesen Quartz-Job sind dann beliebige Trigger definierbar und das alles zur Laufzeit verwaltbar.

[1] Spring Batch Webseite
[2] Buch: “Spring Batch in Action”
[3] Buch: “Pro Spring Batch”
[4] Spring Framework TaskScheduler
[5] Quartz Scheduler Webseite

We defined the numeric fields of our entities using the wrapper objects with the goal to store NULL (instead of zero) in the database if nothing was entered in the form.

@Entity
public class MyEntity{
...
   @Column(name="NUMERICFIELD")
   private Integer numericField;
...
    //getters and setters
...
}

We access the entities through the backing beans and access their fields directly using their getters and setters using EL (Expression Language) in the Facelets.

public MyEntity getMyEntity(){
    return myEntity;
}
public void setMyEntity(MyEntity myEntity){
    this.myEntity = myEntity;
}

<h:inputText id=”myInputText0″ value=”${myBackingBean.myEntity.numericField}”/>

Due to lack of deeper knowledge of the JSF specifications we were quite surprised seeing zeros instead of nulls in the database after submitting an empty inputText.

After googling around a bit I found some blog and forum posts stating that setting the system property

org.apache.el.parser.COERCE_TO_ZERO=false

– which is a system property of the embedded Tomcat web container – would solve our problem. And it actually did. After setting the system property in the jboss’ startup script null values were stored instead of zeros.

But why? What was the story?
So I started searching in the tomcats documentation where I found:

org.apache.el.parser. COERCE_TO_ZERO

If true, when coercing EL expressions to numbers “” and null will be coerced to zero as required by the specification. If not specified, the default value of true will be used.

Oh,

… as required by the specification.

Ok, so I took a look into the EL’s spec and really, the conversion rules for numbers on page 17 in that document say:

1.18.3 Coerce A to Number type N

• If A is null or “”, return 0.
• …

So, by setting the stated system property we made Tomcat behave differing from the standard EL.
Our team discussed a little bit and then decided to document it and live with it, because we

• have full control over the production server,
• have a dedicated app server instance for our application and
• would have had much effort to change our design as we found problem.

Conclusion:
If you designed your application the way we did and face the same problems like we did, you could use the system property as described in this article.
But if you might have to share your production unit with other applications, I strongly recommend a change of your design.
In that case you should imho think about explicit type conversion in your controller / backing bean instead of directly using your entity there.
Further suggestions are appreciated.

Excel bietet eine Umfangreiche Bibliothek mit Funktionen unter anderem aus den Bereichen Mathematik, Finanz- und Ingenieurswesen. Es bietet Pivottabellen für Auswertungen und vielfältige Möglichkeiten der grafischen Aufbereitung mittels Diagrammen. Zudem liefert Excel mit der Skriptsprache Visual Basic for Applications, kurz VBA, die Möglichkeit Makros aufzuzeichnen, um komplexe, sich wiederholende Aufgaben zu automatisieren. Steigt man tiefer in die Programmierung mit VBA ein, kann man eigenen Funktionen und Funktionsbibliotheken entwickeln, bis hin zu einer völlig eigenständigen (aberauf Excel basierenden) Anwendung. Die zur Programmierung nötige Entwicklungsumgebung, der Visual Basic Editor (VBE), liefert Excel gleich mit.

Ich will hier einen kurze Einstieg in die Entwicklung mit Excel VBA bieten.

Makros

Die für die meisten einfachste und schnellste Art ein VBA Programm zu schreiben dürfe sein es nicht selbst zu schreiben, sondern die Arbeit dem Makrorekorder zu überlassen.

Vor die Aufzeichnung des ersten Makros hat Excel allerdings die Optionen gesetzt. Die Makrofunktionen befinden sich im Ribbon im Register “Entwicklertools”. Dieses Register ist standardmäßig ausgeblendet und wird folgendermaßen sichtbar gemacht:

1. Im Ribbon auf Register “Datei” gehen.
2. Den vorletzten Punkt “Optionen” aufrufen.
3. Im jetzt aufgegangenen Dialog auf der linken Seite “Menüband anpassen” wählen
4. und anschließend in der Liste “Hauptregisterkarten” einen Haken bei “Entwicklertools” setzen:

Nun können wir auf das Register “Entwicklertools” gehen und finden dort im Abschnitts “Code” die Makrofunktionen:

• “Makros”
  Hier erscheint ein Dialog mit dem man seine vorhandenen Makros verwalten und ausführen kann.
• “Makro aufzeichnen” / “Aufzeichnung beenden”
  Mit dieser Funktion wird die Aufzeichnung eines Makros gestartet. Dabei werden alle ausgeführten Befehle in ihrer Reihenfolge zur späteren Wiedergabe aufgezeichnet. Auf diese Weise lassen sich komplexe und wiederkehrende Aufgaben automatisieren.
  
• “Relative Aufzeichnung”
  Diese Option legt fest, ob beim Aufzeichnen der Makros die Zellpositionen absolut, oder relativ gespeichert werden sollen. Soll etwa die rechts von A1 liegende Zelle als B1 gespeichert werden, oder als “Rechts-von-der-aktuellen-Zelle”.
• “Makrosicherheit”
  Diese Funktion ruft das Excel-Sicherheitscenter auf, wo man die Bedingungen zur Ausführung von Makros einstellen kann.

Mit diesem Wissen kann jetzt jeder selbst Makros aufzeichnen:

1. “Makro aufzeichnen”.
2. Name des Makros einstellen.
3. Arbeitsschritte in Excel abarbeiten.
4. “Aufzeichnung beenden”

Über den Dialog “Makros” lässt sich das soeben aufgezeichnete Makro nun jederzeit starten und die aufgezeichneten Schnitte werden automatisch nacheinander ausgeführt.

Da wir für eines unserer Projekte zeitgesteuerte Prozesse benötigen und ich gerade am Architekturkonzept schreibe, habe ich verschiedene Technologien evaluiert. Dabei bin ich auf zwei verschiedene Frameworks gestoßen:

• EJB-Timer
• Quartz-Scheduler

Die Anforderung ist:

Zuverlässig in einem bestimmten Intervall (z.B. täglich um 23.30 Uhr oder an jedem Jahresende) eine Reihe von Prozessen auszuführen. Die Lösung muss mit Java 7 auf dem JBoss 7.0.2 deployed werden.

EJB-Timer:

Vorteil

Um den EJB-Timer nutzen zu können müssen keine externen JAR-Dateien gesucht werden, da alles im javax.ejb-Packet enthalten ist. Die erforderliche JAR-Datei ist im JBoss integriert und im Eclipse-Projekt muss lediglich die JBoss 7.0 Runtime Bibliothek hinzugefügt werden.

Nachteil

Dafür musste ich leider feststellen, dass der „jboss-as-7.0.2.Final“ den <Timer-Service> nicht aktiviert hat. Um dies zu tun muss man die „Standalone-preview.xml“ laden. Dafür muss die standalone.bat (unter Windows) mit folgendem Parameter gestartet werden:

• standalone.bat -server-config=standalone-preview.xml

Es darf dabei nicht vergessen werden, jegliche Änderung, die in der standalone.xml vorgenommen wurde, jetzt auch nochmal in der standalone-preview.xml einzutragen.

Java-Code

Um den Timer-Service zu nutzen, erstellt man eine EJB. Für die Problemstellung bietet sich ein @Singleton an, der per @Startup ausgeführt wird. Mit @Resource bekommt man den SessionContext, der wiederum über die Methode getTimerService() den gewünschten Service anspricht.

Um einen Timer zu erstellen, kennt der Service die Methode createTimer(Date startZeitpunkt, Long intervallInMillisekunden, Serializable nameDesTimers), mit der ein Timer initialisiert wird.

Nach jedem Intervall läuft der Timer in ein Timeout, für das die EJB eine Methode mit der Annotation @Timeout benötigt. Sie muss public void sein und als Übergabeparameter ein Timer-Objekt besitzen. Diese Methode wird bei jedem Timeout ausgeführt.

Problem

Beim ersten Ausprobieren war ich voller Euphorie als ich sah, dass in meinem eingestellten Intervall eine Nachricht auf der Konsole erschien. Als ich jedoch ein weiteres Mal deployed habe musste ich feststellen, dass der erste Timer immer noch lief, obwohl ich die War-Datei gelöscht, den JBoss beendet und wieder neu hochgefahren habe. Nach weiterer Recherche habe ich vom Timer-Service über die Methode getTimers() jeden aktiven Timer mit cancel() beendet. Trotzdem liefen mittlerweile sehr viele Timer weiter.

Scheinbar speichert der JBoss die seralisierten Timer-Objekte in irgendeinen Cache. Jedenfalls habe ich auch nach längerer Recherche nicht herausgefunden wie und wo die abgespeichert werden, bzw. wie ich sie wieder löschen kann. Falls jemand darüber Bescheid weiß, wäre es nett, wenn er mich kontaktieren würde.

Quartz-Scheduler

Vorteil

Für den Quartz-Scheduler werden keine Änderungen in der JBoss-Konfiguration benötigt. Lediglich drei JAR-Dateien müssen dem Projekt beigefügt werden.

• Quartz-all-2.1.3.jar
• Slf4j-api-1.6.1.jar
• Slf4j-log4j12-1.6.1.jar

Diese findet man auf der offiziellen Seite quartz-scheduler.org.

Java-Code

Um den Quartz-Scheduler zu nutzen, benötigt man drei Objekte. Einen Job der ausgeführt werden soll, einen Trigger, der sagt wann und in welchem Intervall der Job ausgeführt werden soll und einen Scheduler, in dem der Job einem Trigger zugewiesen und gestartet wird. Für die Implementierung bietet sich eine @Singleton @Startup EJB an, die beim initialisieren (@PostConstruct) die benötigten Objekte erstellt und den Scheduler startet.

Job

Man benötigt eine JavaKlasse, die das Interface org.quartz.Job implementiert und folgende Methode überschreibt:

• public void execute(JobExecutionContext context) throws JobExecutionException

In dieser Methode kann beliebiger Java-Code stehen, der zeitgesteuert ausgeführt werden soll.

Dieser Job muss mit einem JobDetail-Objekt verbunden werden:

JobDetail jobHolidayTaken = JobBuilder.newJob(HolidayTakenJob.class)
.withIdentity("HolidayTakenJob", "group1")
.build();

Der wird benötigt, da dem Scheduler ein Trigger zusammen mit einem JobDetail-Objekt übergeben wird.

Trigger

Der Trigger dient dazu, ein Intervall und einen Startzeitpunkt zu definieren, in dem ein Job ausgeführt werden soll. Es gibt verschiedene Arten von Triggern. Ich habe den SimpleTrigger und den CronTrigger versucht, wobei dem SimpleTrigger ein Startzeitpunkt und ein Intervall in Millisekunden übergeben werden. Der CronTrigger ist für unsere Problemstellung interessanter, da er über seine CronExpression-language mit dem Kalender klar kommt. Wenn man z.B. an jedem Monatsende einen bestimmten Prozess ausführen will, kommt man mit einem Millisekunden-intervall ohne zusätzliche Logik nicht aus. Die Syntax der CronExpression-language macht das zu einem Kinderspiel:

http://www.quartz-scheduler.org/documentation/quartz-1.x/tutorials/crontrigger

Hinweis: Der Link referenziert auf die alte Version 1.x. Ich habe diese gewählt, da dort die Syntax der CronExpression-language sehr schön dargestellt ist. Für weitere Beispiele gibts auf der Seite den Menüpunkt Quartz 2.1.x (2 Einträge weiter oben).

Beispiel:

Calendar startHolidayTaken = new GregorianCalendar();
startHolidayTaken.set(2012, 1, 2, 16, 45, 0);


CronTrigger crontriggerHolidayTaken = TriggerBuilder
.newTrigger()
.startAt(startHolidayTaken.getTime())
.withIdentity("cronHolidayTaken")
.withSchedule(CronScheduleBuilder.cronSchedule("0 30 23 * * * *"))
.build();

Dieser Trigger wird täglich um 23:30 Uhr in ein Timeout laufen und den Job ausführen, den er im Scheduler zugewiesen bekommt.

Scheduler

Der Scheduler ist so etwas wie der Container, in dem sich die Trigger und die Jobs befinden. Der Scheduler verbindet einen Job mit einem Trigger und sorgt dafür, dass beim Timeout der Job ausgeführt wird.

Beispiel:

Scheduler scheduler = new StdSchedulerFactory().getScheduler();
scheduler.start();
scheduler.scheduleJob(jobHolidayTaken, crontriggerHolidayTaken);


Fazit

Ich habe die Evaluierung mit dem EJB-Timer angefangen, da wir sowieso einen EJB-Container in unserem JBoss haben und ich kein weiteres Framework einbinden wollte.

Da ich mich allerdings einen ganzen Tag mit dem EJB-Timer beschäftigt habe und zu keinem zufriedenstellenden Ergebnis gekommen bin (wie schon erwähnt: Ich würde mich über andere Erfahrungen darüber sehr freuen), habe ich mich für den Quartz-Scheduler entschieden, den ich innerhalb kurzer Einarbeitungszeit so zum Laufen bekommen habe, wie ich es brauchte.

Wie erreicht man das Zusammenspiel? Hierfür bietet jQuery die Funktion “noConflict()” an.

Ein paar Hintergrundinformationen: Hat man die jQuery – Bibliothek importiert auf seine Seite, sind die Funktionen von jQuery mittels “$” oder “jQuery” verfügbar; z.b. ‘jQuery(“div p”).hide();’ oder ‘$(“div p”).hide();’

Verwenden nun andere Skript das ‘$’ – Zeichen um die Funktionen verfügbar zu machen, so kann führt es dazu dass die Funktionen von anderen Bibliotheken nicht verfügbar sind, da jQuery bereits das ‘$’ – Zeichen verwendet.

Was kann also getan werden?

1. jQuery.noConflict();
2. jQuery(“div p”).hide();
3. $(“content”).style.display = ‘none’;

Was wird in diesem Abschnitt getan?

1. Hier sagen wir: Gib dem anderen Skript den Alias ‘$’ zurück; so dass ‘$’ wieder für die andere Bibliothek zur Verfügung steht.
2. Arbeite hier mit “jQuery” um jQuery – spezifische Funktion aufzurufen.
3. Da wir in Zeile 1 “.noConflict()” aufgerufen haben, können wir hier mittels ‘$’ die Funktionen einer anderen Bibliothek aufrufen.

Mittels “.noConflict()” kann auch die Verwendung von 2 unterschiedlichen jQuery – Versionen realisiert werden:

1. <script src=”/domain/lib/js/jQuery1.3.2.js” type=”text/javascript”></script>
2. var jq = jQuery.noConflict();
3. <script src=”/domain/lib/js/jQuery1.5.1.js” type=”text/javascript”></script>
4. var player = jQuery.noConflict();

Was wird hier gemacht?

1. Importieren von einer jQuery – Bibliothek der Version 1.3.2.
2. Setzen eines Aliasses “jq”, so dass alle Funktionalitäten von Version 1.3.2. unter dem Alias “jq” verfügbar sind.
3. Importieren von einer jQuery – Bibliothek der Version 1.5.1.
4. Setzen eines Aliasses “player”, so dass alle Funktionalitäten von Version 1.5.1. unter dem Alias “player” verfügbar sind.

So weit so gut. Doch welche Fallstrickt ergeben sich hieraus?

Es muss im Code darauf geachtet werden, das die beiden Aliasses konsequent verwendet werden!

Folgendes Beispiel demonstiert diesen Fallstrick:

function initEvents(id)
{
var _this = jQuery(this);
var container = _this(id);

var viewSwitch = function(event, state){
…
}

viewContainer.bind(“viewSwitch”, viewSwitch);
}

function init(id)
{
initEvents(id);
}

In HTML – Seite steht folgendes:

jq(“body”).init(“list”));

Auf den ersten Blick sieht dieser Code fehlerfrei aus: Es wird eine Funktion aufgeruf, welche wiederum Events registriert (“bind”). Dies kann beim Starten der Zeit geschehen.

Das Problem liegt allerdings in der Zeile (“var _this = jQuery(this);”). Hier wird die aktive jQuery Bibliothek verwendet (unter dem Alias “jQuery” verfügbar).
Dieses Event ist nun also unter “jQuery” registriert. Wird nun später eine andere jQuery – Version verwendet z.B. 1.5.1, so ist das vorher registrierte Event nicht mehr bekannt, da es unter jQuery 1.3.2. registriert wurde, nicht jedoch unter jQuery 1.5.1. Merke: jQuery zeigt auf die zuletzt importierte jQuery Bibliothek.

Um dies zu verdeutlichen:

1. Import von Version 1.3.2
2. Setzen von Alias “jq” mittels “.noConflict()”.
3. “jQuery” und Alias “jq” zeigen auf Version 1.3.2.
4. Import von Version 1.5.2. <- Hier entsteht das Problem.
5. Setzen von Alias “jPlayer”
6. “jQuery” und Alias “jPlayer” zeigen auf Version 1.5.1.

Die Lösung des Problems: In der Funktion “initEvents” muss statt “jQuery” das Alias “jq” verwendet werden.

Ein Tool das ich im Rahmen einer Arbeit bei einem Kunden kennengelernt habe ist “visual event”. Dieses Tool ist ein sogenanntes Bookmarklet.

Wie funktioniert es und was macht es? Man fügt per Drag’n'Drop von der Seite http://www.sprymedia.co.uk/article/Visual+Event den Button “Visual Event” in die Bookmarkleiste des Browsers.

Danach geht man auf eine beliebige Seite deren Events man untersuchen möchte. Ist die Seite geöffnet, klick man auf das zuvor hinzugefügte Bookmark. Nach kurzer Zeit wird die Seite abgedunkelt und es erscheinen kleine, farbige Kästchen die über die Art des Events (Maus: Klick, Doppelklick, Mouseover; HTML – Events: select, blur, focus sowie UI Events: Key down, Key up etc.).

Fährt man mit der Maus über die Kästchen, erhält man Informationen wo im Skript diese Event behandelt wird.

Sehr hilfreich, wenn man den Überblick verliert, wer was wann wieso wo macht!