felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: ipojo and default values
Date Fri, 11 Nov 2011 08:23:59 GMT
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 <clement.escoffier@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 <clement.escoffier@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 <clement.escoffier@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message