Re: [gemini-dev] Expected ordering when using managed properties

[Andrew Scully <andrewscully@xxxxxxxxx>]

Thanks for the reply, Dmitry.

I'll try and get that logging to you as soon as I can if you think
it'll be useful.

I was wondering if there a standard way to acheive what I want to
achieve using Blueprint (or Gemini Blueprint specifically)?

Basically, I would like to have some OSGI-managed properties injected
into a bean (either through individual setters, an update-method or
constructor args) and to have that injection guaranteed to have
completed before the init-method is called. In this particular case,
the configuration values are final so need not be auto-wired when
changed.

Obviously I could simply have the ConfigurationAdmin service injected
and lookup the properties in Java, but I was hoping to achieve this
declaritively in Blueprint as it's much cleaner.

Cheers, Andy.

On 26 November 2014 at 02:09, Dmitry Sklyut <dmitry@xxxxxxxxxxx> wrote:
> 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
>
>
>
> _______________________________________________
> 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