Monday, November 1, 2010

Porting to virgo - seeing some light

Some weeks ago I started some experimental stuff and tried to port our server to Eclipse Virgo. The code was based on spring configuration mainly, so I thought that I should be able to handle this.

Today I can connect with the client and most services are working fine. But if it has one drawback, it is that I had to build most of the library bundles on my own. And we use a hell of a lot of libraries. Hibernate is still not really OSGi-friendly as are other frameworks. Today a had a fight with JasperReports, which used to cause some headache even without OSGi, but with some drawbacks I finally can run our reports on virgo now.

I still must have an evil jar that wants org.apache.xerces as default instead of I thought I had removed all the xerces jars that come with frameworks here and there, and I cannot see what I have overseen today. I made my way round by setting system properties to the jre implementation which luckily made it work. (I needed at least a simple succes today)

Setting up the bundles correctly caused me some headaches over the last weeks. I had the hell of ExtendedClassNotFoundException, learned a lot about who is using whom in my jars. Some things appaered a little surprising to me as I had to import javax.sql for example in many bundles. I would have guessed that those jre packages are visible by default. But maybe someone explains the reason for this to me one day.

One thing that still annoys me is that virgo tooling for eclipse doesn't support PDE bundles. So I have the PDE and the Spring bundle project nature on some of my shared bundles (i.e. bundles that client and server need both for communication) which is really painful and error prone. Kai Toedter opened an enhancement request on this today.

But all in all its working, still have to do some refactorings on formerly static code that used to be called from main, but its not to far to go. Did not find a true showstopper up to now. When all is done I need to work out a proper Installer that will migrate an exisiting configuration into virgo, but that seems to be not to complicated as virgo con pick up existing property files when I put them in the repo.

Now for today I have two different versions of lucene running in parallel, next step I could throw in a current poi instead of that one jasper report uses.

But most of all I'm looking forward to the ease of deployment on my customers sites in the near future. The day they all will have virgo installed, upgrading the whole thing will simply mean uploading a new release to central virgo and p2 repositories. I still have to think my way to the strategy (what about errors on schema upgrades ? I see them at least at one customer at each new release, customer have data you can't think of in advance) but all in all I'm very happy about that.

I'll be talking about the update scenario in detail at ESE on Wednesday afternoon, so come and talk to me if this is something you are into !


Kai Tödter said...

Thanks for mentioning me, but my first name would be spelled "Kai" :)

Miles Parker said...

Xerces *is* evil (the dependency not the tool). If it didn't exist, we'd all probably have a week of extra time by now. :)

Thomas Kratz said...

Sorry Kai ! :) I corrected it

James Roome said...

You talk about building OSGi bundles for Hibernate etc...
If there a OSGi repository somewhere?

Thomas Kratz said...

No I don't see sth like this. Build your own.