http://fusesource.com/camelone2011/camelone-2011-johan-jeff/
http://gnodet.blogspot.com/2010/03/spring-dm-aries-blueprint-and-custom.html Incorrectly is in quotation marks, basically (my personal opinion) the spring solution (while very understandable) is putting a square peg in a round hole. It is forcing resolution through tccl, forcing context refreshes and reload as well as finding classes via not always your bundle classloader. That leads to really funny behavior. That is it, enough for me to not want to use it, not to mention that BP does all I need for my uses. I really don't like AOP, I don't like the proxies, I don't like the annotations and so on. /je On Sep 30, 2013, at 12:43 PM, Sergey Zhemzhitsky <szh.s...@gmail.com> wrote: > 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 >>>>> >>> >
