Websphere… omg

I just had my first foray into getting a simple war running in a WebSphere application server. Wow – what a nightmare. Man I hope i never have to do that again… what a waste. Just awful.

What’s worse, because it’s so ironic, it’s a spring boot based app which runs perfectly with with ‘java -jar …’ using the embedded tomcat, or jetty, or undertow.


Binding jBPM WorkItemHandlers from a Spring Context

I’ve just spent a lump of time (too much for how simple it really is) working out how to do this with jBPM 6.3 so I’ve added this blog to help those who come after.

This has worked for me – I’m not sure that it’s the ‘right’ or most efficient way to achieve the desired result however.

I’m using Spring Boot with jBPM 6.3 (this is valid for the commercial version too – jBoss BPM Suite 6.2). I’ve successfully loaded all the appropriate jBPM services using the instructions from the jBPM 6.3 documentation (though I’ve translated it to Spring Java config rather than the XML config documented), and am happily deploying and executing services.

The problem comes when trying to load WorkItemHandlers from a Spring context and I’ve fought the good fight for a week or three now on and off trying to find a good way to solve it. It’s taken time because there really isn’t a lot of help out there in Google land other than a gamut of hints indicating that many have had this issue and have solved it eventually but haven’t reflected the solution back out there.

In the end after reading quite a lot of the source code and stepping through a few times I took the suggestion from a thread in the jBoss developer forum and extended org.kie.spring.manager.SpringRuntimeManagerFactoryImpl in order to inject my own implementation of org.kie.api.runtime.manager.RegisterableItemsFactory which has a named list of Spring managed WorkItemHandlers which need to be made available to processes executed by jBPM.

My implementation of RuntimeManagerFactory factory is as follows. I’ve overridden the adjustEnvironment method to force my version of the RegisterableItemsFactory in; this method is called when setting up the runtime environment for a process execution.

package myjbpm.jbpm.common.workitemhandlers.impl;

import org.jbpm.runtime.manager.impl.SimpleRuntimeEnvironment;
import org.kie.api.runtime.manager.RegisterableItemsFactory;
import org.kie.api.runtime.manager.RuntimeEnvironment;
import org.kie.api.runtime.process.WorkItemHandler;
import org.kie.spring.manager.SpringRuntimeManagerFactoryImpl;

 * This extends the jBPM {@link SpringRuntimeManagerFactoryImpl} in order to override {@link
 * SpringRuntimeManagerFactoryImpl#adjustEnvironment(RuntimeEnvironment)} method and put in our
 * own {@link RegisterableItemsFactory} implementation which has a reference to the Spring loaded {@link
 * WorkItemHandler} beans.
public class CustomRegisterableItemsSpringRuntimeManagerFactoryImpl extends SpringRuntimeManagerFactoryImpl {

    private final RegisterableItemsFactory springRegisterableItemsFactory;

    public CustomRegisterableItemsSpringRuntimeManagerFactoryImpl(
            RegisterableItemsFactory springRegisterableItemsFactory) {
        this.springRegisterableItemsFactory = springRegisterableItemsFactory;

    protected void adjustEnvironment(final RuntimeEnvironment environment) {
        ((SimpleRuntimeEnvironment) environment).setRegisterableItemsFactory(springRegisterableItemsFactory);

The matching RegisterableItemsFactory is as follows, notice that I extend jBPM’s DefaultRegisterableItemsFactory in order to maintain default functionality for other item types; these could be overridden to be retrieved from a Spring context also I expect:

package myjbpm.jbpm.common.workitemhandlers;

import org.jbpm.runtime.manager.impl.DefaultRegisterableItemsFactory;
import org.kie.api.runtime.manager.RuntimeEngine;
import org.kie.api.runtime.process.WorkItemHandler;

import java.util.Map;

public class SpringRegisterableItemsFactory extends DefaultRegisterableItemsFactory {

    private final SpringWorkItemHandlerProducer workItemHandlerProducer;

    public SpringRegisterableItemsFactory(SpringWorkItemHandlerProducer workItemHandlerProducer) {
        this.workItemHandlerProducer = workItemHandlerProducer;

    public Map<String, WorkItemHandler> getWorkItemHandlers(final RuntimeEngine runtime) {
        Map<String, WorkItemHandler> workItemHandlers = super.getWorkItemHandlers(runtime);

        return workItemHandlers;

Where the SpringWorkItemHandlerProducer is used to translate the Spring injected java.util.List<NamedWorkItemHandler> into the java.util.Map<String, WorkItemHandler> expected by the RegisterableItemsFactory interface. It is as follows:

package myjbpm.jbpm.common.workitemhandlers.impl;

import myjbpm.jbpm.common.workitemhandlers.SpringWorkItemHandlerProducer;
import myjbpm.jbpm.domain.handler.NamedWorkItemHandler;
import org.kie.api.runtime.process.WorkItemHandler;

import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class SpringWorkItemHandlerProducerImpl implements SpringWorkItemHandlerProducer {

    private final Map&amp;amp;amp;lt;String, WorkItemHandler&amp;amp;amp;gt; workItemHandlers = new HashMap&amp;amp;amp;lt;&amp;amp;amp;gt;();

    public SpringWorkItemHandlerProducerImpl(List<NamedWorkItemHandler> workItemHandlers) {

    public Map<String, WorkItemHandler> getWorkItemHandlers() {
        return workItemHandlers;

    private void mapHandlers(final List<NamedWorkItemHandler> namedWorkItemHandlers) {
        for (NamedWorkItemHandler wih : namedWorkItemHandlers) {
            this.workItemHandlers.put(wih.getTaskName(), wih);

And NamedWorkItemHandler is:

package myjbpm.jbpm.domain.handler;

import org.kie.api.runtime.process.WorkItemHandler;

public interface NamedWorkItemHandler extends WorkItemHandler {
    String getTaskName();

Finally these are wired together using some simple Spring bean configuration as follows:

public RuntimeManagerFactory runtimeManager(JtaTransactionManager transactionManager,
        UserGroupCallback userGroupCallback, RegisterableItemsFactory springRegisterableItemsFactory) {
    SpringRuntimeManagerFactoryImpl managerFactory = new CustomRegisterableItemsSpringRuntimeManagerFactoryImpl(

    return managerFactory;

public RegisterableItemsFactory registerableItemsFactory(
        SpringWorkItemHandlerProducer springWorkItemHandlerProducer) {
    return new SpringRegisterableItemsFactory(springWorkItemHandlerProducer);

public SpringWorkItemHandlerProducer springWorkItemHandlerProducer(
        List<NamedWorkItemHandler> namedWorkItemHandlers) {
    return new SpringWorkItemHandlerProducerImpl(namedWorkItemHandlers);

Feedback welcome – particularly if you know a better way to do this, or can see a potential issue. I’ve only just got this working so it’s possible it’s horribly wrong once I get down the track further.

Scala – Implicit Class

Ok so this isn’t a deep dive into implicit’s in scala but rather a reminder on how helpful they can be. The camp on using implicit in scala is divided as you can use them in several different ways and like everyone you’ll go crazy and use them everywhere, then you’ll stop.

Anyway implicit classes are an ideal way to add functionality to an existing type, huh? Ok so I get fed up of seeing this

val time = LocalTime.now()
val someSpecialTime = SomeSpecialTime(time)

The code to me doesn’t read naturally anymore after using scala and I’d prefer time.toSomeSpecialTime, well there is a way if you use an implicit class:

object Converters {
  implicit class LocalTimeToSpecialTime(val localTime: LocalDateTime) extends AnyVal {
    def toSomeSpecialTime = SomeSpecialTime(time)
    def doSomthingElse = AnotherSpecialTime(time)

Now I can import the class and use it as I want.

The implicit class however can not be top level and MUST be defined in a scope where method calls are allowed -> package, class, object. I tend to wrap them inside an object.

I like to use them as a kind of factory, where a string is passed in and the correct type is returned.

def toSurfaceExtrapMethod: SurfExtrapolationMethod = {
  value match {
    case "SE_NONE" =&gt; SurfExtrapolationMethod.NONE()
    case SE_FLATLINE" =&gt; SurfExtrapolationMethod.FLATLINE()
    case "SE_FLATLINE_TO_ZERO" =&gt; SurfExtrapolationMethod.FLATLINE_TO_ZERO()
    case "SE_WITHIN_TOLERANCE" =&gt; SurfExtrapolationMethod.WITHIN_TOLERANCE()
    case "SE_STEP_UP_WITHIN_TOLERANCE" =&gt; SurfExtrapolationMethod.STEP_UP_WITHIN_TOLERANCE()

Also it’s possible to pass in values so you can have something like

def toRangeType(fixedRange: Option[FixedRange] = None): RangeType = {
  value match {
    case "FIT_BOTH" =&gt; RangeType.FitBoth()
    case "FIT_END" =&gt; RangeType.FitEnd()
    case "FIXED" =&gt; RangeType.Fixed(fixedRange.get)
    case "MIN_START" =&gt; RangeType.MinStart()

So you can do something like

val rangeType = "FIXED".toRangeType(Some(FixedRange.FALSE))

Folding observables with Scala

I had a bunch of observables that I wanted to merge into a single observable and then subscribe to it. I knew that I could use merge but had an unknown sequence size of observables, so how could I do it? Easy I can use the merge and fold functions:-

val obs1: Observable[Int] = Observable.from(Seq(1,2,3,4,5))
val obs2: Observable[Int] = Observable.from(Seq(6,7,8,8,10))
val obs3: Observable[Int] = Observable.from(Seq(11,12,13,14))

val totalObservable = Seq(obs1, obs2, obs3)
  .fold(Observable.just[Int]())((a,b) =&gt; a.merge(b))

totalObservable.foreach(x =&gt; println(s"This is the value ${x}"))

The fold takes in an initial value, in this case “Observable.just[Int]()” followed by the aggregation function “a.merge(b)”. It took me about 30 mins to figure out the syntax, especially around the initial value but the code is clean and clear.

Hibernate and sets – use at your peril

For the past 3 weeks I’ve spent hours tuning the performance in one of the applications we use. Unfortunately rather than spend some time and come up with a proper reporting solution I was tasked to fix the existing solution which is to report off our live transactional system. We use EJB3 on JBoss so hibernate it is, which I personally think is an excellent framework for getting your application up and running quickly. Hibernate have always stated that performance isn’t it’s goal so I can’t blame hibernate for anything I’ve found. I tackled the problem in the usual way, add some sql logging and see what’s really happening and look for the usual suspects, lazy loading, code structure etc. Where I saw collections being loaded up separately I added Join fetches and rerun the reports. This worked really well then I noticed that no matter how I wrote the JPQL it always seemed to be running seperate queries for some of the realtionships. That’s when the bulb flashed they were defined as Sets!!

An example of such a thing:

private Set taxComponents = new HashSet(1);

I understand why sets are used but as I’m in control of what gets put in I can safely use:

 private Collection taxComponents = new ArrayList(1);

So using set’s is great but it comes at a cost and beware it’s not just fetches but deletes and inserts have a similar issue in that they get deleted one by one and then reinserted to ensure uniqueness, so if you do update the set it also has a performance hit.

The performance of the major report moved from 30 mins to 6 mins, still not lightning fast but a good improvement. I could of course move to native SQL but I didn’t want to have to rewrite a load of code to do that.

Weld JUnit 4 Runner

I’ve been having a look at Weld recently and wanted to be able to try some stuff out without a container in JUnit, but couldn’t find a JUnit Runner class to do it for me.

I was really suprised how simple it was:

package org.objectopia.test;

import org.jboss.weld.environment.se.Weld;
import org.jboss.weld.environment.se.WeldContainer;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.InitializationError;

public class WeldJUnit4Runner extends BlockJUnit4ClassRunner {

    private final Class klass;
    private final Weld weld;
    private final WeldContainer container;

    public WeldJUnit4Runner(final Class klass) throws InitializationError {
        this.klass = klass;
        this.weld = new Weld();
        this.container = weld.initialize();

    protected Object createTest() throws Exception {
        final Object test = container.instance().select(klass).get();

        return test;

Now you can do this :

public class PersistenceTest {

    @Inject UserRepository repository;


Because your test class is just another CDI bean, you can inject any bean reference you require.

This is where the power of CDI comes in to play, you can do something like this:

    @Inject @Mock UserRepository userRepository;

And create a producer method to mock it out:

    @Produces @Mock UserRepository createUserRepository() { ... }

The arrogance of Gantt charts

Gantt charts, popularized by Microsoft Project, are a mechanism for managing projects. The idea is that you list all the tasks required to complete a project. You then estimate how long each task will take. Once you figure out the dependencies between the tasks you the layout a plan from left to right connecting up all the dependent tasks. This allows for some parallelism between non dependent tasks. Given the project start date and all the durations you get the project end date.

As long as everyone sticks to the plan, then the project will be completed on time.

Simple, eh? Err – not so fast! The major flaw is that Gantt charts are task focused so when a new task is discovered the project is guaranteed to be late. The reason behind this is that developers are focused on delivery of the tasks they are assigned – not value to the client. Coupled with the truism that tasks will take as much time as they are given and you will be late.

The task-centric approach only hints at the real problem with Gantt charts: that better planning and task discovery up front would have resolved these issues. This is the most deplorable aspect: God-like wisdom can be achieved and would have fixed the problem.

Historically, software development has used the notion of “defined process control” where all aspects of the plan can be controlled, to a low-level and to a high-degree of accuracy. This does not work for most software projects because software development is not a simple undertaking- it is usually a complex process where small changes in the inputs can greatly affect the outcome.

Big, upfront planning that depends on infinite wisdom does not work and the only mechanism we have for complex problems is Empirical Process Control. This is the notion of frequent inspection and adaptation to a process.

Emperical control is _the_ key to Agile software. You’re not are Agile if you don’t have a regular process for improvement – you’re just hacking away.

Gantt charts have no place in an agile process; they are the tool of bluff used by the project manager that really doesn’t understand software development.