You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by Gareth Collins <ga...@gmail.com> on 2011/10/11 02:47:09 UTC
Blueprint and Spring ApplicationContextEvents
Hello,
I have been playing with the Spring DefaultMessageListenerContainer,
trying to get it to start in blueprint.
After searching for a while (and realizing that I was looking at the
old Spring Framework 2.5.6 code :)), it appears that in Spring
version 3+ the MessageListenerContainer(s) is tied even closer to the
spring framework via the Spring SmartLifecycle.
My understanding is that to initialize the
DefaultMessageListenerContainer you need to call both
afterPropertiesSet
and start (in Spring 2.5.6 afterPropertiesSet would call "start" -> in
3.x, Spring will call "start" after the application context has
completed loading). In Blueprint, I can only call the one init method
(afterPropertiesSet)
Now since I know the new Spring 3.x pattern, in blueprint I can create
another bean which takes the Spring bean
(DefaultMessageListenerContainer)
as a constructor arg and in its init-method just calls start on the
Spring bean. Is that the right way to work around this though? Am I
missing
some appropriate blueprint functionality to use?
If there isn't something in blueprint now, do you see something
similar being implemented in the future? If not, I guess my general
question is I assume that
blueprint and the Spring framework functionality will drift further
apart over time?
thanks in advance,
Gareth
Re: Blueprint and Spring ApplicationContextEvents
Posted by Dave Wallace <dw...@UDel.Edu>.
I wonder if anyone tried to integrate Blueprint and Spring (w/o DM). It
would be very nice to have Blueprint to handle services and OSGi
configuration while having all of the utility of Spring and it's various
modules available.
Could one implement some interface like Spring's BeanFactory so that the
Spring context could access beans from the Aries Blueprint context? I
suppose we might also want the reverse, but I do not know if Aries
offers a similar interface.
If such a thing were possible, it might avoid some Spring compatibility
issues as Spring classes would be instantiated within Spring itself.
Dave
On 10/11/2011 08:20 AM, Timothy Ward wrote:
> Hi,
>
> Your approach sounds perfectly reasonable. There is no "start"
> equivalent in blueprint, just init methods. This is obviously
> something new and proprietary in Spring 3.x..
>
> We could conceivably add something like this to blueprint, but in
> general the Apache Aries blueprint container is an implementation of
> the OSGi blueprint specification, not a copy of Spring. If Spring add
> something it is unlikely to turn up in blueprint without a bunch of
> user requests or a spec change.
>
> Another possibility would be to lobby Spring not to break their
> backward compatibility, and to keep core classes to blueprint-friendly
> APIs.
>
> Sorry I don't have better news for you,
>
> Tim
>
>
> > Date: Mon, 10 Oct 2011 20:47:09 -0400
> > Subject: Blueprint and Spring ApplicationContextEvents
> > From: gareth.o.collins@gmail.com
> > To: user@aries.apache.org
> >
> > Hello,
> >
> > I have been playing with the Spring DefaultMessageListenerContainer,
> > trying to get it to start in blueprint.
> >
> > After searching for a while (and realizing that I was looking at the
> > old Spring Framework 2.5.6 code :)), it appears that in Spring
> > version 3+ the MessageListenerContainer(s) is tied even closer to the
> > spring framework via the Spring SmartLifecycle.
> > My understanding is that to initialize the
> > DefaultMessageListenerContainer you need to call both
> > afterPropertiesSet
> > and start (in Spring 2.5.6 afterPropertiesSet would call "start" -> in
> > 3.x, Spring will call "start" after the application context has
> > completed loading). In Blueprint, I can only call the one init method
> > (afterPropertiesSet)
> >
> > Now since I know the new Spring 3.x pattern, in blueprint I can create
> > another bean which takes the Spring bean
> > (DefaultMessageListenerContainer)
> > as a constructor arg and in its init-method just calls start on the
> > Spring bean. Is that the right way to work around this though? Am I
> > missing
> > some appropriate blueprint functionality to use?
> >
> > If there isn't something in blueprint now, do you see something
> > similar being implemented in the future? If not, I guess my general
> > question is I assume that
> > blueprint and the Spring framework functionality will drift further
> > apart over time?
> >
> > thanks in advance,
> > Gareth
RE: Blueprint and Spring ApplicationContextEvents
Posted by Timothy Ward <ti...@apache.org>.
Hi,
Your approach sounds perfectly reasonable. There is no "start" equivalent in blueprint, just init methods. This is obviously something new and proprietary in Spring 3.x..
We could conceivably add something like this to blueprint, but in general the Apache Aries blueprint container is an implementation of the OSGi blueprint specification, not a copy of Spring. If Spring add something it is unlikely to turn up in blueprint without a bunch of user requests or a spec change.
Another possibility would be to lobby Spring not to break their backward compatibility, and to keep core classes to blueprint-friendly APIs.
Sorry I don't have better news for you,
Tim
> Date: Mon, 10 Oct 2011 20:47:09 -0400
> Subject: Blueprint and Spring ApplicationContextEvents
> From: gareth.o.collins@gmail.com
> To: user@aries.apache.org
>
> Hello,
>
> I have been playing with the Spring DefaultMessageListenerContainer,
> trying to get it to start in blueprint.
>
> After searching for a while (and realizing that I was looking at the
> old Spring Framework 2.5.6 code :)), it appears that in Spring
> version 3+ the MessageListenerContainer(s) is tied even closer to the
> spring framework via the Spring SmartLifecycle.
> My understanding is that to initialize the
> DefaultMessageListenerContainer you need to call both
> afterPropertiesSet
> and start (in Spring 2.5.6 afterPropertiesSet would call "start" -> in
> 3.x, Spring will call "start" after the application context has
> completed loading). In Blueprint, I can only call the one init method
> (afterPropertiesSet)
>
> Now since I know the new Spring 3.x pattern, in blueprint I can create
> another bean which takes the Spring bean
> (DefaultMessageListenerContainer)
> as a constructor arg and in its init-method just calls start on the
> Spring bean. Is that the right way to work around this though? Am I
> missing
> some appropriate blueprint functionality to use?
>
> If there isn't something in blueprint now, do you see something
> similar being implemented in the future? If not, I guess my general
> question is I assume that
> blueprint and the Spring framework functionality will drift further
> apart over time?
>
> thanks in advance,
> Gareth