You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Timothy Creswick <Ti...@vorboss.com> on 2013/09/26 15:29:03 UTC
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
Re: Blueprint vs. Spring
Posted by Cristiano Costantini <cr...@gmail.com>.
> 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.
>
+1!!!
Re: Blueprint vs. Spring
Posted by Sergey Zhemzhitsky <sz...@gmail.com>.
Hello Johan, Christian,
Thanks a lot for the links and explanations!
It seems, that still, there is no silver bullet.
Pax exam is pretty cool for integration testing, but test+development phases are much slower than with spring if
we are doing for example some kind of functional testing.
And even with the example of cxf+namespaces - there are always some backing classes under the hood, so two
options are available to configure the cxf (and other components) - by means of namespaces - and this is where
the blueprint shines, and by means of classes - here the behavior of the blueprint and spring should be the same.
But there is not only cxf which provides namespace handlers, there are a lot of libs, which have pretty poor
capabilities to be configured by means of namespaces, and should be configured by declaring of the beans with
the appropriate classes (as an example let's take drools).
So, for each individual case, an appropriate approach should be taken.
Regards,
Sergey
> On 27.09.2013 07:31, Sergey Zhemzhitsky wrote:
>>>> 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
> Unfortunately this is not only an issue with non OSGi ready libs.
> A good example is apache CXF. CXF defines some custom spring and
> blueprint name spaces to make it easier to describe your endpoints and
> proxies.
> In spring dm the impl classes behind the namespaces are loaded using the
> classloader of your user bundle. This means your user bundle has to
> import all the internal packages of cxf. This even can not be automated
> as you do not see these dependencies in the code. So you either end with
> require bundle on all cxf bundles or you have to figure out the import
> package statements by trial and error.
> Blueprint in comparison loads the impls behind the namespaces using the
> classloader of the bundle where the impls are located. So your suer
> bundle does not need to care about the internals. In fact when you look
> at sample applications using blueprint and cxf you normally do not have
> to configure anything by hand.
> Just use the maven bundle plugin and your imports are generated. See
> https://github.com/cschneider/Karaf-Tutorial for some examples.
> In fact I think that spring dm is responsible for a lot of the bad
> experiences people had with OSGi.
> So my recommendation is to use blueprint only or e.g. declarative
> services and do your itests with pax exam. Pax exam is of course another
> step to learn but it works great and your tests are very near the actual
> OSGi platform. So you see most issues already in the itests.
> If your test spring dm contexts outside OSGi then many issues will not
> show because the classloading is different.
> Christian
Re: Blueprint vs. Spring
Posted by Christian Schneider <ch...@die-schneider.net>.
On 27.09.2013 07:31, Sergey Zhemzhitsky wrote:
>>> 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
Unfortunately this is not only an issue with non OSGi ready libs.
A good example is apache CXF. CXF defines some custom spring and
blueprint name spaces to make it easier to describe your endpoints and
proxies.
In spring dm the impl classes behind the namespaces are loaded using the
classloader of your user bundle. This means your user bundle has to
import all the internal packages of cxf. This even can not be automated
as you do not see these dependencies in the code. So you either end with
require bundle on all cxf bundles or you have to figure out the import
package statements by trial and error.
Blueprint in comparison loads the impls behind the namespaces using the
classloader of the bundle where the impls are located. So your suer
bundle does not need to care about the internals. In fact when you look
at sample applications using blueprint and cxf you normally do not have
to configure anything by hand.
Just use the maven bundle plugin and your imports are generated. See
https://github.com/cschneider/Karaf-Tutorial for some examples.
In fact I think that spring dm is responsible for a lot of the bad
experiences people had with OSGi.
So my recommendation is to use blueprint only or e.g. declarative
services and do your itests with pax exam. Pax exam is of course another
step to learn but it works great and your tests are very near the actual
OSGi platform. So you see most issues already in the itests.
If your test spring dm contexts outside OSGi then many issues will not
show because the classloading is different.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Blueprint vs. Spring
Posted by Johan Edstrom <se...@gmail.com>.
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 <sz...@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 <sz...@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 <sz...@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
>>>>>
>>>
>
Re: Blueprint vs. Spring
Posted by Sergey Zhemzhitsky <sz...@gmail.com>.
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 <sz...@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 <sz...@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
>>>>
>>
Re: Blueprint vs. Spring
Posted by Johan Edstrom <se...@gmail.com>.
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 <sz...@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 <sz...@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
>>>
>
Re: Blueprint vs. Spring
Posted by Sergey Zhemzhitsky <sz...@gmail.com>.
>> 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 <sz...@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
>>
Re: Blueprint vs. Spring
Posted by Johan Edstrom <se...@gmail.com>.
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 <sz...@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
>
Re: Blueprint vs. Spring
Posted by Sergey Zhemzhitsky <sz...@gmail.com>.
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
Re: Blueprint vs. Spring
Posted by Johan Edstrom <se...@gmail.com>.
Wit pojosr you can do similar things
Sent from my pressure cooker.
On Sep 26, 2013, at 10:25, Cristiano Costantini <cr...@gmail.com> wrote:
> Hi All,
> I'm curios to know more about Sptring DM classloader issue: what is it
> about?
> is it something that is going to be never solved as Spring DM 1.2.1 is the
> last version before the project moved to Gemini Blueprint?
>
>
> There are 2 main reasons I prefer to use Spring:
> - ability to write a pure spring application and run (and debug!) outside
> of the OSGi environment
> - ability to use custom XML DSL (i.e. the Spring MVC)
>
>
> The first point is very useful for us and I spend some more words on it.
> In in each bundle project, we have a test class with about the following
> code:
>
> public static void main(String[] args) throws IOException {
> ConfigurableApplicationContext springContext =
> new ClassPathXmlApplicationContext("META-INF/spring/beans.xml",
> "META-INF/spring/beans-test.xml");
> }
>
> "META-INF/spring/beans-test.xml" is on "src/test/resources" so it is not
> packaged in the bundle, while on the folder
> "src/main/resources/META-INF/spring/" we also add files usually named
> "beans-osgi.xml" which use Spring DM to reference or define osgi services.
> The file "META-INF/spring/beans.xml" is the big one, which is shared
> between in "deployment" and in "debug", while usually beans-test.xml
> defines mock beans to replace the osgi services defined in beans-osgi.xml
> (but sometime we use CXF to connect to real services on the production
> server).
>
> I wonder however if it is possible to do the same with blueprint (I would
> be happy to migrate to blueprint if the above is possible).
> Anyone knows?
>
> Cristiano
>
>
>
>
>
>
> 2013/9/26 Mike K <mi...@gmail.com>
>
>> 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
>>
>>
Re: Blueprint vs. Spring
Posted by Cristiano Costantini <cr...@gmail.com>.
Hi All,
I'm curios to know more about Sptring DM classloader issue: what is it
about?
is it something that is going to be never solved as Spring DM 1.2.1 is the
last version before the project moved to Gemini Blueprint?
There are 2 main reasons I prefer to use Spring:
- ability to write a pure spring application and run (and debug!) outside
of the OSGi environment
- ability to use custom XML DSL (i.e. the Spring MVC)
The first point is very useful for us and I spend some more words on it.
In in each bundle project, we have a test class with about the following
code:
public static void main(String[] args) throws IOException {
ConfigurableApplicationContext springContext =
new ClassPathXmlApplicationContext("META-INF/spring/beans.xml",
"META-INF/spring/beans-test.xml");
}
"META-INF/spring/beans-test.xml" is on "src/test/resources" so it is not
packaged in the bundle, while on the folder
"src/main/resources/META-INF/spring/" we also add files usually named
"beans-osgi.xml" which use Spring DM to reference or define osgi services.
The file "META-INF/spring/beans.xml" is the big one, which is shared
between in "deployment" and in "debug", while usually beans-test.xml
defines mock beans to replace the osgi services defined in beans-osgi.xml
(but sometime we use CXF to connect to real services on the production
server).
I wonder however if it is possible to do the same with blueprint (I would
be happy to migrate to blueprint if the above is possible).
Anyone knows?
Cristiano
2013/9/26 Mike K <mi...@gmail.com>
> 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
>
>
Re: Blueprint vs. Spring
Posted by Mike K <mi...@gmail.com>.
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