Hello Johan, Could you please provide some links regarding what is wrong and incorrectly implemented with spring-dm container? I know that it has some issues with namespace handling and tccl, but would like to know more reasons to help others to choose an appropriate container.
> 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 <szh.s...@gmail.com> 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 <szh.s...@gmail.com> 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: users@servicemix.apache.org >>>>> 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 >>>> >>
