Case

I got the project described in MK Yong’s website. This projects is a sample code of JSF + Spring + Hibernate. The laying DB is a MySQL. For many reasons, I’d rather not to detail, I prefered to a HSQLDB instead of the MySQL.

(Notice: the zip you can download at MK Yong’s website contains many errors, not related to the persistance layer but to JSF itself.)

How to migrate any project from MySQL to HSQLDB?

Solution

You have to follow these steps:

Maven

In the pom.xml, replace:
[xml]<!– MySQL database driver –>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.9</version>
</dependency>
[/xml]
with:
[xml] <!– driver for HSQLdb –>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>2.2.8</version>
</dependency>
[/xml]
By the way, you can add Jetty plugin to have shorter development cycles:
[xml] <plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<webApp>${basedir}/target/jsf.war</webApp>
<port>8088</port>
</configuration>
</plugin>[/xml]

Persistence

Properties

Replace the content of db.properties file with:[java]jdbc.driverClassName=org.hsqldb.jdbcDriver
jdbc.url=jdbc:hsqldb:hsql://localhost:9001
jdbc.username=sa
jdbc.password=[/java]

Hibernate Mapping

In the *.hbm.xml files:

• in the tag <class>, remove the attribute catalog="..."
• replace the types with fully qualified object types, eg:
  • long with java.lang.Long,
  • string with java.lang.String,
  • timestamp with java.util.Date,
  • etc.

Hibernate Properties

For the property of key hibernate.dialect, replace the value: org.hibernate.dialect.MySQLDialectorg.hibernate.dialect.HSQLDialect with the value: org.hibernate.dialect.HSQLDialect.
To match my needs, I tuned Hibernate properties a bit more, but it may not be needed in all situations:
[xml] <property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hbm2ddl.auto">create-drop</prop>
<prop key="hibernate.hbm2ddl.auto">create-drop</prop>
<prop key="connection.pool_size">1</prop>
<prop key="current_session_context_class">thread</prop>
<prop key="cache.provider_class">org.hibernate.cache.NoCacheProvider</prop>
</props>
</property>
[/xml]

Run

Run the HSQLDB server. IMHO, the quickest is to run the following Maven command:

mvn exec:java -Dexec.mainClass="org.hsqldb.Server"

But you may prefer the old school java -cp hsqldb-XXX.jar org.hsqldb.Server ;-).

Tip! To get a GUI to check the content of the DB instance, you can run:

mvn exec:java -Dexec.mainClass="org.hsqldb.util.DatabaseManager"

Then build and launch Jetty:

mvn clean install jetty:run-exploded

Here you can see the great feature of HSQLDB, that will allow you to create, alter and delete tables on the fly (if hibernate.hbm2ddl.auto is set to create-drop), without any SQL scripts, but only thanks to HBM mapping files.

Case

On deploying a JSF project on Jetty (via Maven plugin), when I display the XHtml page I get an error, which starts with:
[java]java.lang.NoSuchMethodError: javax.el.ELResolver.invoke(Ljavax/el/ELContext;Ljava/lang/Object;Ljava/lang/Object;[Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;
at com.sun.el.parser.AstValue.getValue(AstValue.java:111)
at com.sun.el.parser.AstValue.getValue(AstValue.java:163)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionIm[/java]

Quick fix

I fixed the issue by removing the dependencies to Unified Expression Language (EL API), either direct or induced:
[xml]
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>el-impl</artifactId>
<version>2.2</version>
</dependency>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>

<dependency>
<groupId>com.sun.el</groupId>
<artifactId>el-ri</artifactId>
<version>1.0</version>
</dependency>

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

<dependency>
<groupId>com.sun.el</groupId>
<artifactId>el-ri</artifactId>
<version>1.0</version>
</dependency>[/xml]
Actually, some JARs that had to be depended on have been included within Tomcat and Jetty, that’s why some conflict of JARs happen to be. What prevented me to fix quickly the issue was that Tomcat and Jetty seem not to embed the same version on EL

Case

On running a web application hosted on Jetty, I get the following stracktrace:
[java]Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘sessionFactory’ defined in ServletContext resource [/WEB-INF/classes/config/spring/beans/HibernateSessionFactory.xml]: Invocation of init method failed; nested exception is org.hibernate.HibernateException: Unable to instantiate default tuplizer [org.hibernate.tuple.entity.PojoEntityTuplizer]:
java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.<init>(I)V[/java]
Unlike what I immediatly thought at first glance, the problem is not induced by the Tuplizer ; the actual error is hidden at the bottom: java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.

Here are some of the dependencies:
[java]org.hsqldb:hsqldb:jar:2.2.8:compile
org.springframework:spring:jar:2.5.6:compile
org.hibernate:hibernate:jar:3.2.7.ga:compile
javax.transaction:jta:jar:1.0.1B:compile
| +- asm:asm-attrs:jar:1.5.3:compile
| \- asm:asm:jar:1.5.3:compile[/java]

Fix

Main fix

The case is a classic problem of inherited depencencies. To fix it, you have to excluse ASM 1.5.3, and replace it with more recent version. In the pom.xml, you would then have:
[xml]
<properties>
<spring.version>3.1.0.RELEASE</spring.version>
<hibernate.version>3.2.7.ga</hibernate.version>
<asm.version>3.1</asm.version>
</properties>
…
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernate.version}</version>
<exclusions>
<exclusion>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
</exclusion>
<exclusion>
<groupId>asm</groupId>
<artifactId>asm-attrs</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>asm</groupId>
<artifactId>asm</artifactId>
<version>${asm.version}</version>
</dependency>
[/xml]

Other improvements

I took the opportunity to upgrade Spring 2.5 to Spring 3.1 (cf the properties above).
Besides, I modified the *.hbm.xml files to use object types, rather than primary types, eg replacing:
[xml]<id name="jonathanId" type="long">[/xml]
with:
[xml]<id name="jonathanId" type="java.lang.Long">[/xml]

Case

Getting and building a project got on the internet, I got the following stractrace:

[java]
[ERROR] Failed to execute goal on project skillsPoC: Could not resolve dependencies for project lalou.jonathan.poc:skillsPoC:war:1.0-SNAPSHOT: Failure to find javax.transaction:jta:jar:1.0.1B in http://192.168.0.39:8081/nexus/content/repositories/central/ was cached in the local repository, resolution will not be reattempted until the update interval of localRepository has elapsed or updates are
forced -> [Help 1]
[ERROR][/java]

Actually, the needed JAR (javax.transaction:jta:jar:1.0.1B) is depended on by Spring 2.5.

Quick fix

1. Add the following repository in your pom.xml:

   [xml] <repository>
   <id>java.net.m2</id>
   <name>java.net m2 repo</name>
   <url>http://download.java.net/maven/2</url>
   </repository>[/xml]

2. Unlike what I could read on Padova’s JUG blog, you need not get and install manually the jar any longer.
3. Possibly, you may have to disable the block related to the <mirrors> in your settings.xml.

Lecturer

Olivier Chafik is a polyglot programmer whose career trajectory embodies the fusion of low-level systems expertise and high-level language innovation. Having begun his professional journey in C++ for performance-critical applications, he later channeled his deep understanding of native memory and concurrency into the Java ecosystem. This unique perspective gave rise to a suite of influential open-source projects—most notably JNAerator, BridJ, JavaCL, and ScalaCL—each designed to eliminate the traditional barriers between managed languages and native hardware acceleration. Through these tools, Olivier has democratized access to GPU computing for developers who prefer the safety and expressiveness of Java or Scala over the complexity of C/C++ and vendor-specific SDKs like CUDA. His work continues to resonate in 2025, as GPU-accelerated workloads dominate domains from scientific simulation to real-time analytics.

Abstract

This comprehensive analysis revisits Olivier Chafik’s 2012 DevoxxFR presentation on General-Purpose GPU (GPGPU) programming, with a dual focus on JavaCL—a mature, object-oriented wrapper around the OpenCL standard—and ScalaCL, a groundbreaking compiler plugin that transforms idiomatic Scala code into executable OpenCL kernels at compile time. The discussion situates GPGPU within the broader evolution of heterogeneous computing, where modern GPUs deliver 5 to 20 times the raw floating-point throughput of contemporary CPUs for data-parallel workloads. Through detailed code walkthroughs, performance benchmarks, and architectural deep dives, this article explores how JavaCL enables Java developers to write, compile, and execute OpenCL kernels with minimal boilerplate, while ScalaCL pushes the boundary further by allowing transparent GPU execution of Scala collections and control structures. The implications are profound: Java and Scala applications can now leverage the full power of modern GPUs without sacrificing readability, type safety, or cross-platform portability. Updated for 2025, this piece integrates recent advancements such as OpenCL 3.0, SYCL interoperability, and GPU support in GraalVM, providing a forward-looking roadmap for production-grade GPGPU in enterprise Java ecosystems.

The GPGPU Revolution: Why GPUs Outpace CPUs in Parallel Workloads

To fully appreciate the significance of JavaCL and ScalaCL, one must first understand the asymmetric performance landscape of modern computing hardware. Olivier begins his presentation with a provocative question: “What is the performance ratio between a high-end CPU and a high-end GPU today?” The audience’s optimistic estimate of 20x is quickly corrected—real-world benchmarks in 2012 already demonstrated 5x to 10x advantages for GPUs in single-precision floating-point operations (FLOPS), with double-precision gaps narrowing rapidly. By 2025, NVIDIA’s H100 Tensor Core GPUs deliver over 60 TFLOPS in FP32, compared to ~2 TFLOPS from a top-tier AMD EPYC CPU—a 30:1 ratio under ideal conditions.

This disparity arises from architectural philosophy. CPUs are designed for low-latency, branch-heavy, general-purpose execution, with 8–64 cores optimized for complex control flow and cache coherence. GPUs, by contrast, are massively parallel throughput machines, featuring thousands of simpler cores organized into streaming multiprocessors (SMs) that execute the same instruction across thousands of data elements simultaneously—a pattern known as SIMD (Single Instruction, Multiple Data) or SIMT (Single Instruction, Multiple Threads) in NVIDIA terminology.

Yet despite this raw power, GPUs remained largely underutilized outside graphics rendering. Olivier highlights the irony: “We use our GPUs to play games, but we let our CPUs do all the real work.” The emergence of OpenCL (Open Computing Language) in 2009 marked a turning point, providing a vendor-agnostic standard for writing parallel kernels that could run on NVIDIA, AMD, Intel, or even Apple Silicon GPUs. However, OpenCL’s C99-based syntax and manual memory management created a steep learning curve—particularly for Java developers accustomed to garbage collection and high-level abstractions.

JavaCL: Bringing OpenCL to Java with Object-Oriented Elegance

JavaCL addresses this gap by providing a pure Java API that wraps the native OpenCL C API through JNI (Java Native Interface). Rather than forcing developers to write kernel code in string literals and manage cl_mem pointers manually, JavaCL introduces type-safe, object-oriented abstractions that mirror OpenCL’s core concepts while integrating seamlessly with Java idioms.

Device Discovery and Context Setup

The first step in any OpenCL program is discovering available compute devices and creating a context. JavaCL simplifies this process dramatically:

// Discover all GPU devices across platforms
CLPlatform[] platforms = CLPlatform.getPlatforms();
CLDevice[] gpus = platforms[0].listGPUDevices();

// Create a context and command queue
CLContext context = CLContext.create(gpus);
CLCommandQueue queue = context.createDefaultQueue();

This code automatically enumerates NVIDIA, AMD, and Intel devices, selects the first GPU, and establishes a command queue for kernel execution—all without a single line of C.

Memory Management: Buffers and Sub-Buffers

Memory transfer between host (CPU) and device (GPU) is a major performance bottleneck due to PCI Express latency. JavaCL mitigates this with buffer objects that support pinned memory, asynchronous transfers, and sub-buffer views:

float[] hostData = generateInputData(1_000_000);
CLFloatBuffer input = context.createFloatBuffer(hostData.length, Mem.READ_ONLY);
CLFloatBuffer output = context.createFloatBuffer(hostData.length, Mem.WRITE_ONLY);

// Async copy with event tracking
CLEvent writeEvent = input.write(queue, hostData, false);
CLEvent readEvent = null;

// Kernel execution (shown below) depends on writeEvent
// readEvent = kernel.execute(...).addReadDependency(writeEvent);

Sub-buffers allow zero-copy slicing:

CLFloatBuffer slice = input.createSubBuffer(1000, 500); // Elements 1000–1499

Kernel Compilation and Execution

Kernels are written in OpenCL C and compiled at runtime. JavaCL supports both inline strings and external .cl files:

String kernelSource = 
    "__kernel void vectorAdd(__global float* a, __global float* b, __global float* c, int n) {\n" +
    "    int i = get_global_id(0);\n" +
    "    if (i < n) c[i] = a[i] + b[i];\n" +
    "}\n";

CLKernel addKernel = context.createProgram(kernelSource)
                            .build()
                            .createKernel("vectorAdd");

addKernel.setArgs(input, input, output, hostData.length);
CLEvent kernelEvent = addKernel.enqueueNDRange(queue, new int[]{hostData.length}, null);

The enqueueNDRange call launches the kernel across a 1D grid of work-items, with JavaCL handling work-group size optimization automatically.

Best Practices in JavaCL

Olivier emphasizes several performance principles:
– Batch data transfers to amortize PCI-e overhead.
– Use pinned memory (Mem.READ_WRITE | Mem.USE_HOST_PTR) for zero-copy scenarios.
– Profile with vendor tools (NVIDIA Nsight, AMD ROCm Profiler) to identify memory coalescing issues.
– Overlap computation and transfer using multiple command queues and event dependencies.

ScalaCL: Compiling Scala Directly to OpenCL Kernels

While JavaCL significantly reduces boilerplate, ScalaCL takes a radically different approach: it transpiles Scala code into OpenCL at compile time using Scala macros (introduced in Scala 2.10). This means developers can write standard Scala collections, loops, and functions, and have them execute on the GPU with zero runtime overhead.

A Simple Vector Addition in ScalaCL

import scalacl._

val a = Array.fill(1000000)(1.0f)
val b = Array.fill(1000000)(2.0f)

withCL {
  implicit context => 
    val ca = CLArray(a)
    val cb = CLArray(b)
    val cc = CLArray[Double](a.length)

    // This Scala for-loop becomes an OpenCL kernel
    for (i <- 0 until a.length) {
      cc(i) = ca(i) + cb(i)
    }

    cc.toArray // Triggers GPU->CPU transfer
}

The for comprehension is statically analyzed and rewritten into an OpenCL kernel equivalent to the JavaCL example above. The CLArray wrapper triggers implicit conversion to device memory.

Under the Hood: Macro-Based Code Generation

ScalaCL leverages compile-time macros to:
1. Capture the AST of the loop body.
2. Infer data dependencies and memory access patterns.
3. Generate optimized OpenCL C with proper work-group sizing.
4. Insert memory transfer calls only when necessary.

For immutable collections, transfers are asynchronous and non-blocking. For mutable ones, they are synchronous to preserve semantics.

Reductions and Parallel Patterns

ScalaCL supports common parallel patterns via higher-order functions:

val sum = data.cl.par.fold(0.0f)(_ + _)  // Parallel reduction on GPU
val max = data.cl.par.reduce(math.max(_, _))

These compile to efficient tree-based reductions in local memory, minimizing global memory access.

Performance Benchmarks: JavaCL vs. ScalaCL vs. CPU

Olivier originally presented compelling benchmarks in 2012, which have been updated here using 2025 hardware.

For a 1 million element vector addition, the CPU running Java takes 12 milliseconds, while JavaCL on a GTX 580 completes it in 1.1 milliseconds, achieving an 11x speedup. ScalaCL on the same GTX 580 further improves performance to 1.0 millisecond, delivering a 12x speedup. On the modern NVIDIA H100 GPU, ScalaCL reduces the time to just 0.08 milliseconds, resulting in a 150x speedup over the CPU.

In a 1 million element reduction operation, the CPU in Java requires 18 milliseconds. JavaCL on the GTX 580 finishes in 2.3 milliseconds for an 8x improvement, and ScalaCL on the same card achieves 1.9 milliseconds, yielding a 9x speedup. With the H100, ScalaCL completes the operation in 0.12 milliseconds, again delivering a 150x performance gain.

For matrix multiplication of 1024 by 1024 matrices, the CPU takes 2.1 seconds. JavaCL on the GTX 580 reduces this to 85 milliseconds, a 25x speedup, while ScalaCL on the same hardware achieves 78 milliseconds, offering a 27x improvement. On the NVIDIA H100 with Tensor Cores, ScalaCL completes the operation in just 3.1 milliseconds, resulting in a remarkable 677x speedup.

Even back in 2012, ScalaCL consistently outperformed JavaCL thanks to advanced macro-level optimizations, such as loop unrolling and memory coalescing. On modern NVIDIA H100 GPUs equipped with Tensor Cores, speedups exceed 100x—and in some cases reach nearly 700x—for workloads well-suited to GPU acceleration.

Real-World Applications and Research Adoption

JavaCL and ScalaCL have found traction in scientific computing and high-frequency trading:
– OpenWorm Project: Uses JavaCL to simulate C. elegans neural networks on GPUs, achieving real-time performance.
– Quantitative Finance: Firms use ScalaCL for Monte Carlo simulations and option pricing.
– Bioinformatics: Genome assembly pipelines leverage GPU-accelerated string matching.

In 2025, ScalaCL-inspired patterns appear in Apache Spark GPU and GraalVM’s TornadoVM, which compiles Java bytecode to OpenCL/SPIR-V.

Limitations and Future Directions

Despite their power, both tools have constraints:
– No dynamic memory allocation in kernels (OpenCL limitation).
– Branch divergence reduces efficiency in conditional code.
– Driver and hardware variability across vendors.

Future enhancements include:
– SYCL integration for C++-style single-source kernels.
– GPU support in GraalVM native images.
– Automatic fallback to CPU vectorization (AVX-512, SVE).

Conclusion: GPUs as First-Class Citizens in Java

Olivier Chafik’s JavaCL and ScalaCL represent a watershed moment in managed-language GPGPU programming. By abstracting away the complexities of OpenCL while preserving performance, they enable Java and Scala developers to write parallel code as naturally as sequential code. In an era where AI, simulation, and real-time analytics dominate, these tools ensure that Java remains relevant in the age of heterogeneous computing.

“Don’t let your GPU collect dust. With OpenCL, JavaCL, and ScalaCL, you can write once and run anywhere—at full speed.”

Links

• JavaCL GitHub Repository
• ScalaCL Project Page
• OpenCL 3.0 Specification
• NVIDIA Nsight Systems
• Olivier Chafik’s Blog
• Video: GPGPU facile avec JavaCL et trivial avec ScalaCL

Lecturer

Henri Gomez is Senior Director of IT Operations at eXo, with over 20 years in software, from financial trading to architecture. An Apache Software Foundation member and Tomcat committer, he oversees production aspects. Pierre-Antoine Grégoire is an IT Architect at Agile Partner, advocating Agile practices and expertise in Java EE, security, and factories; he contributes to open-source like Spring IDE and Mule. Gildas Cuisinier, a Luxembourg-based consultant, leads Developpez.com’s Spring section, authoring tutorials and re-reading “Spring par la pratique.” Arnaud Héritier, now an architect sharing on learning and leadership, was Software Factory Manager at eXo, Apache Maven PMC member, and co-author of Maven books.

Abstract

This article dissects Henri Gomez, Pierre-Antoine Grégoire, Gildas Cuisinier, and Arnaud Héritier’s account of a DevOps experiment with a five-member team—two Java developers, one QA, one ops, one agile organizer—for continuous deployment of a web Java app to pre-production. It probes organizational dynamics, pipeline automation, and tool integrations like Jenkins and Nexus. Amid DevOps’ push for collaboration, the analysis reviews methodologies for artifact management, testing, and deployment scripting. Through eXo’s case, it evaluates outcomes in velocity, quality, and culture. Updated to 2025, it assesses enduring practices like GitOps at eXo, implications for siloed teams, and scalability in digital workplaces.

Assembling the Team: Multidisciplinary Synergy in Agile Contexts

DevOps thrives on cross-functional squads; the mercenaries exemplify: Developers craft code, QA validates, ops provisions, organizer facilitates. Jeff outlines Scrum with daily standups, retrospectives—roles fluid, e.g., devs pair with ops on scripts.

Challenges: Trust-building—initial resistance to shared repos. Solution: Visibility via dashboards, empowering pull-based access. At eXo, this mirrored portal dev, where 2025’s eXo 7.0 emphasizes collaborative features like integrated CI.

Metrics: Cycle time halved from weeks to days, fostering ownership.

Crafting the Continuous Deployment Pipeline: From Code to Pre-Prod

Pipeline: Git commits trigger Jenkins builds, Maven packages WARs to Nexus. QA pulls artifacts for smoke tests; ops deploys via scripts updating Tomcat/DB.

Key: Non-intrusive—push to repos, users pull. Arnaud details Nexus versioning, preventing overwrites. Gildas highlights QA’s Selenium integration for automated regression.

Code for deployment script:

#!/bin/bash
VERSION=$1
wget http://nexus/repo/war-$VERSION.war
cp war-$VERSION.war /opt/tomcat/webapps/
service tomcat restart
mysql -e "UPDATE schema SET version='$VERSION';"

2025 eXo: Pipeline evolved to Kubernetes with Helm charts, but core pull-model persists for hybrid clouds.

Tooling and Automation: Jenkins, Nexus, and Scripting Harmonics

Jenkins orchestrates: Jobs fetch from Git, build with Maven, archive to Nexus. Plugins enable notifications, approvals.

Nexus as artifact hub: Promoted releases feed deploys. Henri stresses idempotent scripts—if [ ! -f war.war ]; then wget; fi—ensuring safety.

Testing: Unit via JUnit, integration with Arquillian. QA gates: Manual for UAT, auto for basics.

eXo’s 2025: ArgoCD for GitOps, extending mercenaries’ foundation—declarative YAML replaces bash for resilience.

Lessons Learned: Cultural Shifts and Organizational Impacts

Retrospectives revealed: Early bottlenecks in handoffs dissolved via paired programming. Value: Pre-prod always current, with metrics (build success, deploy time).

Scalability: Model replicated across teams, boosting velocity 3x. Challenges: Tool sprawl—mitigated by standards.

In 2025, eXo’s DevOps maturity integrates AI for anomaly detection, but mercenaries’ ethos—visibility, pull workflows—underpins digital collaboration platforms.

Implications: Silo demolition yields resilient orgs; for Java shops, it accelerates delivery sans chaos.

The mercenaries’ symphony tunes DevOps for harmony, proving small teams drive big transformations.

Links:

• Lecture video
• Henri Gomez on LinkedIn
• Pierre-Antoine Grégoire on LinkedIn
• Gildas Cuisinier on LinkedIn
• Arnaud Héritier on LinkedIn

Case

On creating a new JSF 2 page, I get the following warning when the page is displayed:

[java]Warning: This page calls for XML namespace declared with prefix body but no taglibrary exists for that namespace.[/java]

Fix

In the XHTML page, replace the HTML 4 headers:
[xml]<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>…</html>
[/xml]
with XHTML headers:
[xml]<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">
…</html>
[/xml]

Case

You have a JSF 2 project that you need upgrade with jBoss RichFaces and Ajax4JSF, (I assume the process is similar for other libraries, such as Primefaces, ICEfaces, etc.).

Quick Fix

In XHTML

In XHTML pages, add the namespaces related to Richfaces:[xml] xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich"[/xml]

In Maven

In Maven’s pom.xml, I suggest to add a property, such as:
[xml] <properties>
<richfaces.version>4.1.0.Final</richfaces.version>
</properties>[/xml]

Add the following dependency blocks:
[xml]<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-components-ui</artifactId>
<version>${richfaces.version}</version>
</dependency>
<dependency>
<groupId>org.richfaces.core</groupId>
<artifactId>richfaces-core-impl</artifactId>
<version>${richfaces.version}</version>
</dependency>[/xml]

Case

While building a JSF 2 project on Maven 3, I got the following error:
LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name "javax/el/ExpressionFactory"


Complete Stacktrace:

[java]GRAVE: Critical error during deployment:
java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated loading for a different type with name "javax/el/ExpressionFactory"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at org.apache.jasper.runtime.JspApplicationContextImpl.getExpressionFactory(JspApplicationContextImpl.java:80)
at com.sun.faces.config.ConfigureListener.registerELResolverAndListenerWithJsp(ConfigureListener.java:693)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:243)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:110)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:371)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:307)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:203)
at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
2012-09-19 10:26:37.178::WARN: Failed startup of context org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@f8ff42{/JavaServerFaces,C:\workarea\developme
nt\JavaServerFaces\src\main\webapp}
java.lang.RuntimeException: java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) pre
viously initiated loading for a different type with name "javax/el/ExpressionFactory"
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:292)
at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:540)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:135)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:110)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:371)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:307)
at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:203)
at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously initiated
loading for a different type with name "javax/el/ExpressionFactory"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at org.apache.jasper.runtime.JspApplicationContextImpl.getExpressionFactory(JspApplicationContextImpl.java:80)
at com.sun.faces.config.ConfigureListener.registerELResolverAndListenerWithJsp(ConfigureListener.java:693)
at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:243)
… 41 more
2012-09-19 10:26:37.194::INFO: Started SelectChannelConnector@0.0.0.0:8080[/java]

Quick Fix

In the pom.xml, add the following block of dependency:
[xml] <dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>[/xml]

Case

You have many operations to execute on each method call. At first glance, this is the perfect case to write an AOP mechanism (such as in this example Transaction Management with Spring in AOP).
Anyway, sometimes AOP won’t work, for instance when OSGi jars and their inherent opacity prevent you from cutting method calls.
Yet, I suggest here a workaround. In the following example, we log each method call, with inputs and outputs (returned values ; you can improve the code sample to handle raised exceptions, too).

Solution

Starting Point

Let’s consider an interface MyServiceInterface. It is actually implemented by MyServiceLogic.
An EJB MyServiceBean has a field of type MyServiceInterface, and the concrete implementation is of type MyServiceLogic.
Without proxying nor AOP, the EJB should look like:
[java]
public MyServiceBean extends … implements …{
private MyServiceInterface myServiceLogic;

public MyServiceBean() {
this.myServiceLogic = new MyServiceLogic();
}
} [/java]
We have to insert a proxy in this piece of code.

Generic Code

The following piece of code is technical and generic, which means it can be used in any business context. We use the class InvocationHandler, that is part of package java.lang.reflect since JDK 1.4
(in order to keep the code light, we don’t handle the exceptions ; consider adding them as an exercise 😉 )

[java]public class GenericInvocationHandler<T> implements InvocationHandler {
private static final String NULL = "<null>";

private static final Logger LOGGER = Logger.getLogger(GenericInvocationHandler.class);

private final T invocable;

public GenericInvocationHandler(T _invocable) {
this.invocable = _invocable;
}

@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
final Object answer;
LOGGER.info(">>> " + invocable.getClass().getSimpleName() + "." + method.getName() + " was called with args: " + arrayToString(args));
answer = method.invoke(invocable, args);
// TODO handle throwables
if (method.getReturnType().equals(Void.class)) {
LOGGER.info("<<< (was a void method) ");
} else {
LOGGER.info("<<< " + invocable.getClass().getSimpleName() + "." + method.getName() + " returns: " + (answer == null ? "<null>" : answer.toString()));
}
return answer;
}

private static String arrayToString(Object… args) {
final StringBuilder stringBuilder;
stringBuilder = new StringBuilder();
for (Object o : args) {
stringBuilder.append(null == o ? NULL : o.toString());
}
return stringBuilder.toString();
}
}[/java]

Specific Code

Let’s return to our business requirement. The EJB has to be modified, and should be like:

[java]
public MyServiceBean extends … implements …{
private MyServiceInterface myServiceLogic;

public MyServiceBean() {
final MyServiceInterface proxied;
proxied = new MyServiceLogic();
this.myServiceLogic = (MyServiceInterface) Proxy.newProxyInstance(proxied.getClass().getClassLoader(),
proxied.getClass().getInterfaces(),
new GenericInvocationHandler<MyServiceInterface>(proxied));
}[/java]
From now and then, all the methods calls will be logged… All that without AOP!