Hello Mike, >> If you are Ok with restarting whole SMX container than Spring DM is Ok. Could you please provide some more info or examples for this case? I'm asking because we're using spring-dm mainly (there were no an easy way to test blueprint-based camel routes at the time we were migrating to servicemix).
Regarding blueprint there are some cons like 1. issues with generics https://issues.apache.org/jira/browse/ARIES-960 2. no aop support, like with spring (aop namespace with aspectj expressions) 3. blueprint is intended to be used with OSGi 4. blueprint does not have lookup method injection but spring-dm is pretty obsolete. It would be great if there would be some kind of spring-blueprint bridge, so that it would be possible to export any spring beans as osgi services, and use any osgi service references imported by blueprint within a spring context. Regards, Sergey > 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
