Hi Timothy,
Go with Blueprint.
To be clear - the Spring in SMX is Spring DM that allows Spring context in
OSGi.
The Spring DM has classloader issue. This impacts bundle restart and
upgrade.
If you are Ok with restarting whole SMX container than Spring DM is Ok.
Keep in mind that not everything might be implemented in Blueprint vs Spring
DM
Mike
-----Original Message-----
From: Timothy Creswick
Sent: Thursday, September 26, 2013 6:29 AM
To: [email protected]
Subject: Blueprint vs. Spring
Hi,
We're working with a new ServiceMix deployment (v4.5) with a view to
migrating a lot of distinct business process applications to the platform.
Most of our existing web front-ends are Spring web apps, so we're very
familiar with using Spring Framework. Existing back-ends are a huge variety
of technologies and will all be re-written. We're intending for modules to
all communicate over JMS (so that there is requirement to have modules in
the same OSGi container).
When researching ServiceMix several months ago I'm sure I read some
references suggesting that Blueprint is the preferred method. Right now, we
can [realtively] easily pick either Blueprint or Spring, although my
preference would be to primarily only use one in order to minimise training.
Blueprint appears to be a bit more elegant, although I can't quite put my
finger on why that is. I gather it should also handle dependency injection
better than Spring, although we're using a relatively small subset of 3rd
party libs.
I primarily wanted to get a sense of:
1. What are people mostly using?
2. What are the advantages / issues with your chosen approach?
3. With hindsight, would you change it?
Also, are there any major gotchyas if we pick one method or the other (i.e.
something that we won't be able to do later without changing things)?
Many thanks,
Tim
