[gemini-dev] Expected ordering when using managed properties

[Andrew Scully <andrewscully@xxxxxxxxx>]

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.