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: [email protected] > To: [email protected] > > 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
