Hello Andrew, I have a strong feeling that this is up to the underlying osgi framework. Sometimes you might get configuration sooner than blueprint context is able to initialize all of the beans in the context.
If you could enable logging on org.springframework and org.eclipse.gemini.blueprint.compendium and send it my way, I will try to make a more educated guess. There are no locks/waits for the delivery of configuration to the update method, it is fully async. Kind Regards, Dmitry On Tue, Nov 25, 2014 at 5:58 AM, Andrew Scully <[email protected]> wrote: > Hi, > > I have a question relating to using managed OSGI configuration within > a Blueprinted bundle. > > Lets say I have a declaration that looks like this: > > <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xmlns:cm=" > http://www.eclipse.org/gemini/blueprint/schema/blueprint-compendium"; > xmlns:ctx="http://www.springframework.org/schema/context"; > xmlns:beans="http://www.springframework.org/schema/beans"; > > xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 > http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd > http://www.eclipse.org/gemini/blueprint/schema/blueprint-compendium > > http://www.eclipse.org/gemini/blueprint/schema/blueprint-compendium/gemini-blueprint-compendium.xsd > http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans.xsd > http://www.springframework.org/schema/context > http://www.springframework.org/schema/context/spring-context.xsd";> > > <bean id="testBean" class="com.test.TestBean" init-method="start" > destroy-method="stop"> > <cm:managed-properties persistent-id="test.testbean" > update-method="configurationUpdated" /> > </bean> > > </blueprint> > > > There is a init-method and an update-method on TestBean, the update > method being set with a Map of properties. > > > My question is: Is it clearly defined what order the init and update > methods should be called in, both on startup and during a bundle > update? > > I would expect the update method to be called before the init method > -- otherwise the bean will be starting up without knowing its > configuration. > > > I seem to be getting a problem with one of our low-level (first to > start) services, in which occasionally the start method is called > before the update method, even though valid configuration is available > for the persistent ID. > > Synchronising the start and update methods seemed to help at first > (presumably the start method was being called before the update method > had finished), but now we seem to be getting it again, suggesting the > the start method is being called first. > > We get the same issue when the configuration values are injected as > properties. > > Is this the expected behaviour? > > > This is on Gemini Blueprint 1.0.2.RELEASE, Spring 3.1.4, Apache Felix > 4.2.1 (within Glassfish 4.0/4.1). > > > Cheers, Andy. > _______________________________________________ > gemini-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/gemini-dev >
_______________________________________________ gemini-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/gemini-dev
