December 3rd was a great morning – I had the opportunity to give a short presentation of [fleXive] at the Sun Business Breakfast in Vienna/Austria. The feedback received was very valueable and I think we are on the right track with [fleXive] – there is a high demand for secure and multilingual content centric frameworks supporting agile development.
Slides are available for download here (german).
[fleXive] run-once and startup scripts provide an easy way for running customized code at application installation and server startup time inside the EJB container (documentation).
Today I checked in code that allows those scripts to be stored in any JAR file of your application (previously a build task had to index the files and store them under a unique path). This greatly simplifies the usage of those scripts in custom projects that do not use the distribution’s build infrastructure.
To execute run-once scripts from a JAR file, you have to:
flexive-application.properties contains at least the application name and may provide additional information about your [fleXive] application:
# Application name
name=hello-flexive
displayName=Hello World Application# The web application context root (if any)
contextRoot=war
For an example create a new project using the current version of our EAR archetype for Maven (instructions). In the “shared” module you find two scripts that will be executed at application startup time:
|– shared
| |– pom.xml
| `– src
| `– main
| |– java
| `– resources
| |– ApplicationMessages.properties
| |– flexive-application.properties
| `– scripts
| |– runonce
| | `– 01-runonce.groovy
| `– startup
| `– 01-startup.groovy
The implementation is based on a JarInputStream, the JAR filename is extracted from the URL of the flexive-application.properties resource. A simplified version is shown below:
[Update 2009/04/30: fixed the JAR read method. Apparently JarInputStream#read delivers data in arbitrary sized chunks, which was not really clear to me from looking at the documentation alone]
final Enumeration<URL> fileUrls =
Thread.currentThread()
.getContextClassLoader()
.getResources("flexive-application.properties");
while (fileUrls.hasMoreElements()) {
final String path =
fileUrls.nextElement().getPath()
.replace("/flexive-application.properties", "");
final JarInputStream jarStream =
new JarInputStream(new URL(path).openStream());
JarEntry entry;
while ((entry = jarStream.getNextJarEntry()) != null) {
if (!entry.isDirectory()
&& entry.getName().startsWith("scripts/startup/")) {
int offset = 0;
int readBytes;
while ((readBytes = jarStream.read(buffer, offset, (int) entry.getSize() - offset)) > 0) {
offset += readBytes;
}
if (offset == entry.getSize()) {
final String code = new String(buffer, "UTF-8");
// do something...
}
}
}
jarStream.close();
}
A new [fleXive] snapshot (build 937) is available in the downloads section.
It features full JBoss 5.0.0 GA compatibilty and includes the H2 database as optional database backend as well as Maven build support.
After focusing on feature completeness and ironing out the inevitable bugs the time has come to see if [fleXive]‘s core is really as portable to other database backends than MySQL as intended and designed.
The idea was to use a native Java database for the (expected) small footprint and to be able to provide a platform independent installer. The current installer is only available for Windows and contains an embedded MySQL 5.0 installation. Another reason – as Daniel mentioned in his blog entry about Maven – was to be able to download and distribute [fleXive] using the Maven 2.0 buildsystem and be able to include a database which is easy to run, install and maintain.
Why H2? Well initially I wanted to use Apache Derby / JavaDB since I already embedded it in other customer projects but since I never worked with H2 and only heard great things about it I wanted to give it a try and see how things work out.
To make a long story short: it worked out great! I am impressed by the performance H2 has to offer and the compatibility to the MySQL dialect, although I stumbled across a few issues and gotcha’s:
insert into ... (select ... from) will throw an error while the same statement without the parentheses works like a charm: insert into ... select ... from … maybe a bug in the parser?set @rownum=0; and then incrementing it in a select statement using @rownum:=@rownum+1. The first gotcha is that assignments with := do not work, but they do without the colon. This seemed to work well, but somehow the ordering was no longer correct. After some searching the (rather simple but not too intuitive) solution was to use the SET function: SET(@rownum, @rownum+1) instead.statement.setQueryTimeout(15/*seconds*/); is not working and will prevent the query from being executed (at least for me).
. Using the (experimental) MVCC locking I could work around this issue but it is still not a perfect solution. Aside from the pitfalls and gotcha’s mentioned above, porting was straight forward and done in less time than I expected. I had to write some (Java) stored procedures to create some needed compatibility functions when dealing with Dates and Timestamps or recoding MySQL’s handy CONCAT_WS function but no real issues there at all.
H2 is an excellent pure Java database that still has some minor rough edges but can definitely be recommended! The small footprint of about 1MB is amazing considering it contains a complete webserver and user interface. It is overall very fast – for small amounts of data it even beats MySQL, although storing blob’s take a bit too long for my liking.
Now back to updating the [fleXive] documentation on how to use H2 …
Who said JavaEE servers have to be resource hogs? It turns out that the combination of Jetty, OpenEJB and H2 mentioned in the Maven integration article is actually relatively lightweight in terms of memory usage (for a JavaEE application, that is).
While it required some fixes to get the [fleXive] content cache under control, a [fleXive] application including the backend clocks in at about 40 megabytes heap usage (Linux, 32 bit). Looking at the system resources reveals slightly less encouraging numbers, but still more than manageable even on a shared host:
25587 11335 158440 247972 30.4 4.7 /usr/lib/jvm/java-6-sun/bin/java -Xmx64M -client -classpath /usr/share/maven2/boot/classworlds.jar -Dclassworlds.conf=/usr/share/maven2/bin/m2.conf -Dmaven.home=/usr/share/maven2 org.codehaus.classworlds.Launcher “jetty:run” “-Dflexive.cache.config=cacheconfig.xml”
This means about 150 MB of memory for the web and EJB containers, the (in-process) H2 database engine, all flexive libraries (about 30 MB in compressed JAR files), and the cluster-enabled JBoss Cache.
Since Maven and Jetty already consume about 70 MB of memory right after startup (I assume most of it is on Maven), it should be possible to reduce memory usage considerably by launching Jetty outside Maven (but then I’d lose the convenient dependency injection, so I left it at that for now).
A tested snapshot of the current development branch has been released ([fleXive] download page, browse Sourceforge release).
This release offers two major new features over 3.0 (still under development, but definitely usable!):
A major meta feature is of course the Maven support mentioned in the last post – Maven support has been added for all released [fleXive] versions, including 3.0 and 3.0.1.
