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
