Archive for the ‘jboss’ Category

Drools persistence on top of HashMap
February 7, 2011


This post shows a reference implementation of drools persistence on top of a non transactional HashMap. This should serve as inspiration for more complex scenarios (like the Berkley DB one). This work was also developed under Intalio’s sponsorship.

As the new abstraction is heavily inspired on JPA there are some mechanisms which should be emulated in order to get the same behavior on both implementations.

Involved classes

Starting from the abstraction described in my previous post this is the new hierarchy for persisting drools runtime into a HashMap.

Drools abstract storage persistence diagram

Drools abstract storage persistence diagram

I’ll try to explain the most relevant objects in the diagram relating them to JPA components.

behaves like the EntityManager, it stores all objects which are not yet commited. Finding objects is also resolved through this interface, for support this behavior it has to have access to the KnowledgeSessionStorage.
represents the real persistent storage. This is the extension point for support any other non-JPA implementation. It provides saveOrUpdate and find methods and is the responsible to assign id’s to the entities.
as we cannot rely on JTA to manage our session Drools hooks explicit calls whenever things should be serialized. This component must access the NonTransactionalPersistenceSession to get the entities waiting for being persisted into the KnowledgeSessionStorage.


The same concepts have been applied into JBPM5 codebase and we have there proper extensions for managing process semantics.

You’ll find there:

  • MapBasedProcessPersistenceContext
  • ProcessStorage
  • ManualProcessTransactionManager
  • etc


You must setup the environment you gonna pass to the JPAKnowledgeService (still keeping the name for backward compatibility) setting the TRANSACTION_MANAGER and PERSISTENCE_CONTEXT_MANAGER keys. For this I have just created simple factories but you can build them the way you want.

I suggest using KnowledgeSessionStorageEnvironmentBuilder or ProcessStorageEnvironmentBuilder. There doesn’t exist a default implementation of this storage, the one on top of HashMap is only used for testing porposes, so you have to pass to the builder your own implementation of the desired storage.

Testing further implementations

To test this two implementations (and any new one which wants to respect the drools persistence semantic) together, I have created a simple set of abstract tests(*).
For Drools Expert:[…]/
For JBPM5[…]/
In a future will be great to abstract the current tests on JPA to be able to run abstract of the lower persistence layer.

What’s next

Clean up this interfaces a bit more and start working on a DB Berkley implementation

(*) tests names are not declarative enough, I’m holding a commit for this until coming repository split is done


Are you ready for Drools 5.2 + jbpm5?
December 16, 2010

Great things are happening into the core of Drools and it will impact into the whole community.
This post is not about the great features we gonna have soon but about how to make the transition painless.
From the developer point of view things are getting better and better.

    Git migration
    Maven 3 compliance
    Repository cleanup (no more .classpath and .project files)
    Guvnor building coming less and less painful
    Huge internal refactors and optimizations

The major of this tasks were leaded by ge0ffrey who has made our lives a lot better :)

As regular user of the framework when you finally decide to move from 5.1.1 to 5.2 you will find a big difference. Drools Flow is gone… but it has reborn as JBPM5!.
So the concepts remains the same but you’ll need to adjust your dependencies and make a reorganization of your imports. This is the first step on breaking backward compatibility preparing us for the big crash arriving on 6.0 :)
Basically u gonna need to add

  <artifactId>jbpm-[flow | persistence-jpa | bpm2 | ...]</artifactId>

Doing so you should change a lot of your org.drools packages into org.jbpm.


Drools Flow :: Work Items
April 19, 2010


Working on improve our knowledge about the Drools platform and to give something back to the community. This time we’ll discuss a language extension called Work Items. The official documentation says: “[Drools Flow] offers constructs that are closely related to the problem the user is trying to solve”. In other words, creating your own WorkItems lets you extend the business modeling language to a domain oriented way.
Creating a language for your process gives you an enormous flexibility in what you can express. The funny thing is that with this great power doesn’t come a great responsibility, meaning there is no more responsibility than needed to write any bored and unflexible process language.


Nace JBug Argentina
May 6, 2009