You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Bengt Rodehav <be...@rodehav.com> on 2011/10/27 23:35:24 UTC
ipojo and default values
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.
/Bengt
Re: ipojo and default values
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <be...@rodehav.com>
> Thanks Clement,
>
> /Bengt
>
>
> 2011/11/11 Clement Escoffier <cl...@gmail.com>
>
>>
>> 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 <cl...@gmail.com>
>> >
>> >> 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 <cl...@gmail.com>
>> >>>
>> >>>> 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 <cl...@gmail.com>
>> >>>>>
>> >>>>>> 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: users-unsubscribe@felix.apache.org
>> >>>>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >>>> For additional commands, e-mail: users-help@felix.apache.org
>> >>>>
>> >>>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> >> For additional commands, e-mail: users-help@felix.apache.org
>> >>
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
Re: ipojo and default values
Posted by Bengt Rodehav <be...@rodehav.com>.
Thanks Clement,
/Bengt
2011/11/11 Clement Escoffier <cl...@gmail.com>
>
> 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 <cl...@gmail.com>
> >
> >> 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 <cl...@gmail.com>
> >>>
> >>>> 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 <cl...@gmail.com>
> >>>>>
> >>>>>> 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: users-unsubscribe@felix.apache.org
> >>>>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ipojo and default values
Posted by Clement Escoffier <cl...@gmail.com>.
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 <cl...@gmail.com>
>
>> 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 <cl...@gmail.com>
>>>
>>>> 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 <cl...@gmail.com>
>>>>>
>>>>>> 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: users-unsubscribe@felix.apache.org
>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and default values
Posted by Bengt Rodehav <be...@rodehav.com>.
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?
/Bengt
2011/11/10 Clement Escoffier <cl...@gmail.com>
> 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 <cl...@gmail.com>
> >
> >> 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 <cl...@gmail.com>
> >>>
> >>>> 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: users-unsubscribe@felix.apache.org
> >>>> For additional commands, e-mail: users-help@felix.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ipojo and default values
Posted by Clement Escoffier <cl...@gmail.com>.
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 <cl...@gmail.com>
>
>> 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 <cl...@gmail.com>
>>>
>>>> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and default values
Posted by Bengt Rodehav <be...@rodehav.com>.
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?
I have been thinking about adding "synchronize" to my @Validate callback.
Would this be a solution? Would you recommend or argue against it?
/Bengt
2011/11/8 Clement Escoffier <cl...@gmail.com>
> 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 <cl...@gmail.com>
> >
> >> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ipojo and default values
Posted by Clement Escoffier <cl...@gmail.com>.
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 <cl...@gmail.com>
>
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: ipojo and default values
Posted by Bengt Rodehav <be...@rodehav.com>.
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).
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.
/Bengt
2011/10/28 Clement Escoffier <cl...@gmail.com>
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: ipojo and default values
Posted by Clement Escoffier <cl...@gmail.com>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org