Hi Neil,
> The the component is *using* a configuration record (i.e. is has been
> activated with that record) and if it does not have a Modified method, then
> it must be deactivated when the configuration record is deleted.
That is what I thought. The activate methode doesn’t have the properties
parameter though...
public void activate() throws Exception {
… and the component does have a modified() method, so I am not sure why the
component needs to be deactivated. I expected the framework ‘just’ call
modified() with a null properties map.
Erwin
> This part is, so far, the same for both optional and required configuration.
>
> After the deactivation, a component with optional configuration is now
> allowed to re-activate with no configuration, i.e. using its own internal
> defaults. A required-configuration component would NOT be allowed to
> reactivate until a new configuration record came along.
>
> So yes, this is the behaviour I would expect to see.
>
> Neil
>
>
> On Tue, Jan 23, 2018 at 12:16 PM, Erwin Hogeweg via osgi-dev
> <[email protected] <mailto:[email protected]>> wrote:
> Hi,
>
> We noticed, in an equinox OSGi framework with felix scr and
> felix.file-install, that a component’s deactivate() and activate() methods
> are called when the component’s configuration file is removed. Actually the
> config file was updated but it looks like the file-install thread caught it
> halfway in the replace process.
>
> Is it expected that the deactivate() and activate() methods are called when
> an optional configuration is removed? I am trying to find something about
> that in the OSGi specs, but so far w/o luck.
>
>
> Regards,
>
> Erwin
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
