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 <[email protected]> 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 <[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 _______________________________________________ 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
