I now have this code.
* @Validate*
* synchronized public void starting() throws Exception {*
* init();*
* mIsValid = true;*
* }*
*
*
* @Invalidate*
* synchronized public void stopping() {*
* mIsValid = false;*
* terminate();*
* }*
*
*
* @Updated*
* synchronized public void updated() throws Exception {*
* // Do nothing if we are not valid yet*
* if (mIsValid) {*
* terminate();*
* init();*
* }*
* }*
This seems to work fine. I don't know if this is best practice for how you
handle configuration changes when you need to acquire/release resources
every time the configuration changes. In my case I start an Http context,
register servlets etc in the init() method. I the terminate() method I
unregister the same.
/Bengt
2011/11/11 Bengt Rodehav <[email protected]>
> Thanks Clement,
>
> /Bengt
>
>
> 2011/11/11 Clement Escoffier <[email protected]>
>
>>
>> On 11.11.2011, at 09:23, Bengt Rodehav wrote:
>>
>> > Clement,
>> >
>> > I use an @Updated callback today. In the callback I check if certain
>> > important properties have changed and if so, I trigger a
>> re-initialization.
>> > Would this work if I make both m @Validate callback and my @Updated
>> > callback synchronized? Or do I have to introduce setter methods as well
>> on
>> > those properties and make them synchronized?
>>
>> Yes it will work. Then you're sure that callback won't be executed at the
>> same time.
>>
>> Regards,
>>
>> Clement
>>
>> >
>> > /Bengt
>> >
>> > 2011/11/10 Clement Escoffier <[email protected]>
>> >
>> >> Hi,
>> >>
>> >> On 09.11.2011, at 12:08, Bengt Rodehav wrote:
>> >>
>> >>> Thanks for you reply Clement although I'm not sure I understand it
>> >> entirely.
>> >>>
>> >>> I use ManagedServiceFactories as well when I want to instantiate an
>> >>> arbitrary number of iPOJO instances. When I require exactly one
>> instance
>> >>> then I use a ManagedService.
>> >>>
>> >>> Although I think I understand why you recommend using a
>> >>> ManagedServiceFactory to solve the problem (I guess it forces only
>> one
>> >>> thread to call my callbacks instead of two threads), it doesn't seem
>> >> like a
>> >>> scenario where ManagedServiceFactories should be used. Isn't it some
>> kind
>> >>> of deficiency if my configuration is updated in the midst of my
>> @Validate
>> >>> callback? How can I ever be sure of having a consistent configuration?
>> >>
>> >> If you really want to be check the configuration after every
>> >> reconfiguration, then you should use setter method or the updated
>> callback.
>> >>
>> >>>
>> >>> I have been thinking about adding "synchronize" to my @Validate
>> callback.
>> >>> Would this be a solution? Would you recommend or argue against it?
>> >>
>> >> It won't be enough, you should also synchronize the setter method of
>> your
>> >> property. In that case, you can be sure that the reconfiguration won't
>> be
>> >> applied during the @Validate method execution.
>> >>
>> >> Regards,
>> >>
>> >> Clement
>> >>
>> >>>
>> >>> /Bengt
>> >>>
>> >>>
>> >>> 2011/11/8 Clement Escoffier <[email protected]>
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> Sorry for this pretty late reply…
>> >>>>
>> >>>> On 28.10.2011, at 11:05, Bengt Rodehav wrote:
>> >>>>
>> >>>>> Hello Clement,
>> >>>>>
>> >>>>> I have used the @Updated annotation (haven't tried the @Property on
>> a
>> >>>> method
>> >>>>> though). The problem is that the @Updated method is called while
>> I'm in
>> >>>> the
>> >>>>> midst of executing the @Validate method (which uses the property
>> that
>> >> is
>> >>>>> being changed). I guess this must be done on separate threads
>> (haven't
>> >>>>> checked).
>> >>>>
>> >>>> Yes, the @Updated method is with the config admin thread, while
>> >> @Validate
>> >>>> is called by the iPOJO processing thread.
>> >>>>
>> >>>>>
>> >>>>> Having updates of the configuration taking place while executing an
>> >> iPOJO
>> >>>>> callback (like the @Validated method) doesn't really make sense to
>> me.
>> >>>> For
>> >>>>> me, it means that I use the old value (8093) in my @Validate method
>> >>>> instead
>> >>>>> of the new value (9991). I know that OSGi is a very dynamic
>> environment
>> >>>> and
>> >>>>> the configuration can change at any time. Therefore I do
>> reinitialize
>> >> my
>> >>>>> iPOJO when certain values change. The problem is that I'm only
>> informed
>> >>>> once
>> >>>>> about configuration changes (@Updated) and if that happens when I'm
>> in
>> >>>> the
>> >>>>> @Validated method I miss the opportunity.
>> >>>>>
>> >>>>> I'm probably approaching this the wrong way but do you know what
>> best
>> >>>>> practice is for the following:
>> >>>>>
>> >>>>> - Having a configuration property with a default value
>> >>>>> - Using the configuration property to initialize the iPOJO
>> >>>>> - Doing the initialization when the iPOJO becomes valid and
>> >>>> re-initializing
>> >>>>> whenever the property changes
>> >>>>> - It must be guaranteed that the re-initialization is never done
>> until
>> >>>> the
>> >>>>> first initialization has been completed (in the @Validate method)
>> and I
>> >>>> must
>> >>>>> not "miss" any re-initialization.
>> >>>>>
>> >>>>
>> >>>> If you want to be sure you get only one value, you should use a
>> >>>> ManagedServiceFactory instead of a ManagedService. Then you configure
>> >> the
>> >>>> instance with the new value (if not set will use the default value).
>> By
>> >>>> using a ManagedServiceFactory configuration, iPOJO will creates the
>> >>>> instance (so no need of @Instance) with the right configuration.
>> >>>>
>> >>>> Regards,
>> >>>>
>> >>>> Clement
>> >>>>
>> >>>>
>> >>>>> /Bengt
>> >>>>>
>> >>>>>
>> >>>>> 2011/10/28 Clement Escoffier <[email protected]>
>> >>>>>
>> >>>>>> Hi,
>> >>>>>>
>> >>>>>>
>> >>>>>> On 27.10.2011, at 23:35, Bengt Rodehav wrote:
>> >>>>>>
>> >>>>>>> I'm using iPOJO and have problems with default property values.
>> >>>> Consider
>> >>>>>> the
>> >>>>>>> following:
>> >>>>>>>
>> >>>>>>> * @Property(name = "url", mandatory = true, value = "
>> >>>>>>> http://localhost:8093/service";)*
>> >>>>>>> * private String mUrl;*
>> >>>>>>>
>> >>>>>>> If I use config admin (with fileinstall) to provide an override to
>> >> the
>> >>>>>> "url"
>> >>>>>>> property (changing the port from 8093 to 9991), then the following
>> >>>>>> happens:
>> >>>>>>>
>> >>>>>>> 1. My @Update method is called. The port is 8093.
>> >>>>>>> 2. My @Validate method is called. It does some initialization that
>> >> can
>> >>>>>> take
>> >>>>>>> a second or two. On entering the @Validate method the port is
>> 8093.
>> >>>>>>> 3. My @Update method is called again. The port is now 9991 which
>> >> means
>> >>>>>> that
>> >>>>>>> this is the value from config admin. Note that my @Validate
>> method is
>> >>>> not
>> >>>>>>> done at this point.
>> >>>>>>> 4. My @Validate method returns. At this point the port is 9991.
>> >>>> However,
>> >>>>>> the
>> >>>>>>> initialization code in the @Validate method used the port 8093 not
>> >> 9991
>> >>>>>> that
>> >>>>>>> I wanted to use.
>> >>>>>>>
>> >>>>>>> I expected the port 9991 to be used since I had overridden the
>> >> default
>> >>>>>> port
>> >>>>>>> (8093). I'm not sure why this is happening. How can I guarantee
>> that
>> >>>> the
>> >>>>>>> overridden port is used instead of the default port?
>> >>>>>>>
>> >>>>>>> Note that since the update to port 9991 takes place while I'm in
>> my
>> >>>>>>> @Validate method I missed the update and I won't be informed
>> about it
>> >>>>>> again.
>> >>>>>>
>> >>>>>> If you want to be notified after a reconfiguration, you can use
>> >>>> @Property
>> >>>>>> on a method (called when the value is injected) or use the @Updated
>> >>>> called
>> >>>>>> when a reconfiguration occurred (and when the reconfiguration is
>> >>>> completed).
>> >>>>>>
>> >>>>>> @Validate is called only once (or after an invalidation).
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>>
>> >>>>>> Clement
>> >>>>>>
>> >>>>>>>
>> >>>>>>> /Bengt
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> ---------------------------------------------------------------------
>> >>>>>> To unsubscribe, e-mail: [email protected]
>> >>>>>> For additional commands, e-mail: [email protected]
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: [email protected]
>> >>>> For additional commands, e-mail: [email protected]
>> >>>>
>> >>>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [email protected]
>> >> For additional commands, e-mail: [email protected]
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
