>> 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
>>
