Wednesday, November 20, 2013

JBoss 7.2: From Aries to Gemini and back again

I have been using the combination of JBoss 7.2 and Apache Aries for a while now.
Recently, I had to face a problem, which I had been ignoring for quite a while successfully.

When you use Aries blueprint you cannot use setters with non-void return values. Aries expects setters to have "void" as their return type.
Because fluent interfaces are quite popular at the moment that was a problem for me.
The Aries people already have an open issue to fix/improve this and maybe the blueprint specification also wants setters to have that return type. I don't want to start a discussion about this here.

Nevertheless, I wanted to use the setter. I could have written a subclass with a slightly different setter, which just calls the setter I really want to use. But that would've meant to write a new setter for every existing one. So that was not an option.

Another option was to change the Aries source code by myself (what I should have done in the first place). But I didn't know how complex that would be so I chose the third option.

The option I chose was to replace Aries with Gemini. At some point during my research I found a post, which stated that Gemini could handle non void return values for setters.
After I managed to collect all of Gemini's dependencies and place them in JBoss' bundle directory I thought I reached my goal. But when I started the server it didn't go past the registration of my EJBs. The server log just showed a NPE some seconds before when trying to release some lock.

I wasn't sure what to do because the NPE wasn't really helpful and I couldn't imagine what the problem was. My only idea was to remove the Jar containing the EJBs.
After that the server started but the Blueprint-Extender didn't start automatically. That wasn't much of a deal. I opened up the management console and started the bundles all by hand. Everything seemed to be fine. Even dropping the EJB-Jar in the deployment directory worked.
Unfortunately, after stopping and starting the server again I was staring at the same exception and the JBoss refused to do its work.
What followed was some try-and-error with more error than try. I still don't know what the problem is.

This was really disappointing (it still is). I decided to take the option I refused before and to change Aries' code. Fortunately I had the Gemini-Jars in another local JBoss so I could just go back to the one I had used before.
And who could've guessed? I just had to change one line in org.apache.aries.blueprint.utils.ReflectionUtils:

if (name.length() > 3 && name.startsWith("set") && 
resultType == . && argTypes.length == 1)
I just had to remove the Void.TYPE and everything worked.
I guess next time I'll try to change the code first ;)


Post a Comment


Copyright @ 2013 Wrong tracks of a developer.

Designed by Templateiy