Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gemini-dev] Expected ordering when using managed properties

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 <andrewscully@xxxxxxxxx> 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
gemini-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gemini-dev


Back to the top