Spring-dm as a container is what is implemented "incorrectly" As for your other arguments, sure, it is your decision.
On Sep 26, 2013, at 11:31 PM, Sergey Zhemzhitsky <[email protected]> wrote: >>> You can use spring beans and vice versa in blueprint >>> Nothing says you can't test beans in spring and deploy in BP either > We do not have to use neither spring nor blueprint for testing separate beans. > The drawbacks of such an approach are: > 1. Two separate DI/IoC frameworks in the same app for the same purposes > 2. There are no any guarantee with compatibility (take a look at ARIES-960), > as > spring has more powerful DI capabilities > 3. There is unit testing for testing separate beans, so neither spring nor > blueprint needed. > >>> you may have to force classloaders or unravel proxies > Its possible in both spring as well as blueprint > >>> You can test blueprint with micro services and pax exam, pojo sr > 1. pax exam is pretty heavyweight > 2. pojosr+blueprint out of the box is possible with camel blueprint testing > afaik, > so even if there are no any integration flows it will be necessary to > introduce > camel deps just for testing, correct? > >>> The big problem is the conversion of matrix classloading to an ee >>> classloader and context resets > I suppose, this issue is relevant to improperly implemented libs only > (without OSGi in mind) > and neither spring nor blueprint do not solve this issue of of the box. > > Kind Regards, > Sergey > >> You can use spring beans and vice versa in blueprint, you may have >> to force classloaders or unravel proxies. >> You can test blueprint with micro services and pax exam, pojo sr. >> Nothing says you can't test beans in spring and deploy in BP either. > >> The big problem is the conversion of matrix classloading to an ee >> classloader and context resets. > > > >> Sent from my pressure cooker. > >> On Sep 26, 2013, at 12:10, Sergey Zhemzhitsky <[email protected]> wrote: > >>> 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 >>> >
