Axonframework on servicemix

Imported from Google Groups
#1

Hi All,

We wrote a simple application using axonframework and we are very pleased by it. We now want to run it in our osgi container and we will soon convert axon to be osgi compatible. Before we move forward i was wandering if anyone has done this before and can share some code suggestions with us.

If no one did it before we will be happy to share the code with anyone interested.

#2

Hi Alberto,

I have done quite a bit of OSGi work in the past, but haven’t used in in combination with Axon yet. However, I have been thinking about making the jars OSGi compatible (since it doesn’t affect ‘normal’ applications). I just didn’t get to it yet.

If you could provide some code/configuration, that would be great!

Cheers,

Allard

#3

Hi Allard,

I will wrap axonframework shading it the same way does servixmix to support not compatible osgi bundles. I will then create a simple project and share it here.

if that works we will then collaborate with you to make the framework osgi compatible.

thanks
Alberto

#4

Hello,

Currently at the company I work we use OSGi and I wanted to use Axon in one of our projects. We use the Apache Karaf OSGi container.
First off, Axon is not OSGi compatible and by that I do not meen it hasn’t got the OSGi headers in the manifest file but rather two huge problems I’m having right now and still havn’t got it working.

  1. Axon uses ServiceLoader in some (lot) places. This does not work in OSGi ServiceLoader at the bottom uses Thread.currentThread().getContext() which does not work in OSGi.
  1. Axon uses Class.forName in its serializers. This is currently a problem I do not have a solution for. The problem I have is deserialization of sagas that live in a separate bundle. Serialization is not an issue but when a saga gets deserialized then I get ClassNotFoundExceptions because at the time of deserialization the axon osgified bundle has no access to the saga class it need to create using Class.forName. DynamicImport-Package OSGi headers is not an acceptable solution for me.

To recap … currently I’m having nightmares with axon in a OSGi environment.
I’m still trying to solve this Class.forName problem. If I’m successful I will let you know.

Regards, Ivica

#5

Hi Ivica,

it’s been a while sine I have done anything with OSGi, so these things weren’t in the top of my mind when designing Axon. However, I do see a lot of potential in using Axon in OSGi environments. Your remarks will definitely help me improve Axon in that area.

Regarding the ServiceLoader, I will see if it’s feasible to expose the method that do a lookup on an explicit classloader. There has been a discussion already about injecting the ParameterResolver instead of hard-coding the service loader mechanism. That would make it easer to inject an OSGi compatible implementation.

The serializers should be easy to make OSGi compatible. If I remember correctly, the XStream instance can be configured with a ClassLoader instance. And instead of Class.forName (which I believe uses the class loader of the invoking class), I would use the configured classloader.

I’m going to have a look at this. Meanwhile, if you have any ideas or comments, please let me know.

Cheers,

Allard

#6

Hi Allard,

I’m too using Equinox OSGI container. One thing that comes to my mind when combining OSGI and Axon is the ability to register EventHandlers on the fly via in bundles/fragments.

Regards,

Setya

#7

Hello,

I was able to solve the Class.forName solution by implementing my own serializer which has a registerClass method which in turn enables me to add classes to the serializer from other bundles.

My custom serializer has a filed like :

private final Map<String, Class> registeredClasses = new HashMap<String, Class>();

and a method like:

public void registerClass(String key, Class klass) {
this.registeredClasses.put(key, klass);
}

then in classForType, serialize and desirialize I use this registry.

Of course I also neede to make a new Serializer interface which extends axons with the registerClass method :slight_smile:

Because i register the serializer as a service in an OSGi environment and by default that service is a singelton all my bundles that depend on the serializer can now register classes to it.

This currently solves my problem.

Regards, Ivica

#8

Hi,
I’ve recently started working with axon and OSGi and generally speaking when I run into serialization issues I use a different approach which I’ve seen in some other project (karaf-cellar, hibernate-osgi, etc): basically it consists in a custom class-loader that delegates the class loading to a bundle.

So I have a custom class loader that:

  • listen for bundles life-cycle and cache them if they are eligible (e.g. if the symbolic name starts with my.domain)
  • delegate the class loading to the bundles it currently knows

Then I set the my class loader to the serializer (e.g. XStream.setClassLoader)
You can find the lower-than-alpha quality code there: https://github.com/lburgazzoli/lb-karaf-examples

#9

Hello,

Elegant idea … i will probably use it for the next milestone of our project.

Tnx.

Regards, Ivica

#10

Oh, and just a piece of warning :slight_smile:

I’ve done extensive debugging (remote debugging with intellij) on a running karaf instance with my axon bundles and found out this ServiceLoader problems the hard way. The bundle was activated … no startup issues whatsoever but for some reasons the events and commands where suddenly dying on me. The debugger helped me to nail down the problem to the ServiceLoader trying to load classes and failing. Because axon eats up those exceptions and never propagates them I never so any indication of an error when in the karaf logs with log:set DEBUG. Maybe there is a way to say to axon to log those errors (I recall seeing somewhere in the axon code a mentioning of a DEBUG mode where everything is logged) but I did not find it in the documentation.

So if something is not working but you have no logs of an error the primary suspect is the ServiceLoader problem.

This issue was solved for me by using the Aries SPY-Fly module.

Regards, Ivica

#11

Thx Ivica.

Do you know where and for which reason does axon use ServiceLoader?

#12

Hi Luca,

I can answer that one :wink:
The ServiceLoader is used for a few reasons: the first is for the IdentifierFactory, which is used to generate the identifiers for the Events. By default, UUID.random() is used. However, its performance is not great, so some projects use another generator. The serviceloader is used to find a factory on the classpath.
Another use case is the contenttype converter used by upcasters. ServiceLoader is used to locate available converters in the applications.

At least the latter can be replaced by injection, instead of a ServiceLoader lookup.

Cheers,

Allard

#13

Hi Allard,It would be really nice to have a ServiceRegistry interface an then some concrete implementations:

  • the default one that automatically resolve/loads the objects trough the ServiceLoader
  • some specific implementations for JNDI, OSGi, etc
  • a chain of registries that delegate the operation to the parent if required object is not found

Well, that is in fact how the Apache Camel framework works and when it runs in an OSGi container the bundle Activator dynamically scans the bundles to register in its runtime objects ‘exposed’ via ServiceLoader. Then there is an OSGiRegistry that does a lookup in OSGi before to delegate the lookup to another registry.

How complex would be to introduce the above implementation? If it some think you’d like to introduce of course :slight_smile:

Thx - Luca

#14

Hi Luca,

Lots of food for thought. I’ve been playing with the idea to provide proper OSGi support in Axon, as many concepts would work really well with OSGi’s dynamic behavior.

I distinguish between two ways of ‘supporting’ something. One is to not be in the way, and allow developers to make required modifications (subclasses or implementations of interfaces). The other is to actually provide the specific building blocks. Currently, in terms of priority, OSGi support is at the first stage.

However, it would really be nice to have an axon-core-osgi package that bundles the axon-core and provides some additional building blocks for Axon in an OSGi environment. I can’t really say how complex it would be to introduce this, at the moment. I first need to figure out what needs to be modified. Obviously, all contributions are welcome :wink:

Cheers,

Allard

#15

Hi Allard,
I would love too an axon-core-osgi!

In fact I’ve fell in love with axon, osgi and a couple of other framework I’m playing with and I’ll be more than happy to contribute to your great framework :slight_smile: Just show me the way :slight_smile: