felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: uses ComponentInstances as part of the Declarative Services specification
Date Wed, 18 Dec 2013 07:32:33 GMT
I've studied the spec some more and I think that:

-- the component factory service should not be unregistered and reregistered if an optional
static reference is removed.  I base this on 112.5.5 where it says that the factory service
does not bind to any of the references.  It remains satisfied while the optional reference
is removed, so there seems to be no reason to unregister it.

-- the component created from newInstance should be disposed of and not recreated.  I base
this on the end of 112.5.5 which says

Once a component configuration created by the Component Factory has been deactivated, that
com- ponent configuration will not be reactivated or used again.
Removing an optional static reference causes the configuration to be deactivated, so it should
not be reactivated and reused.  So I think there's a bug in 1.6.2 here.  Before I spend much
time investigating would you be able to see if the recent 1.8 release has the same behavior?


I'm not 100% convinced that this is really the intent of the spec.  Does anyone else have
an idea?


However, with the current behavior, it occurs to me that you might be able to solve your problem
by, rather than caching the object returned from ComponentInstance.getInstance, caching the
ComponentInstance and retrieving the object each time you want to use it.  Then if the object
is replaced, you'll get the new one.
 Thanks!

david jencks

On Dec 17, 2013, at 5:09 PM, "Humeniuk, David P" <David.Humeniuk@udri.udayton.edu> wrote:

> What I'm seeing is that the ComponentFactory service instance (referenced by what is
called an AssetFactory, i.e., the ComponentFactory will create an Asset type) is not unregistered
when the optional static reference goes away.  I'm seeing only the component instance itself
being recreated (i.e., the Asset).  If the ComponentFactory was unregistered that would be
good because then my service (the AssetDirectoryService) that keeps track of the instances
would be notified as it has a reference to the AssetFactory.  However, I'm not see any evidence
of the AssetFactory being deactivated (due to its ComponentFactory service reference being
unregistered).  What I do see is the service provided by the Asset being unregistered and
registered again.  This makes it look like the component instance is re-created automatically.
> 
> As far as configuration goes, I do have the AssetDirectoryService register a ManagedServiceFactory
that has some base properties and it adds other properties from the AssetFactory instance.
 These properties are then made available to the Asset component, but through some helper
methods that associate a PID with the Asset instance.
> 
> I'm using scr-1.6.2 BTW.
> 
> Thanks,
> Dave
> 
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com] 
> Sent: Tuesday, December 17, 2013 6:02 PM
> To: users@felix.apache.org
> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
> 
> DS is certainly not ignoring the static reference policy.
> 
> I'm slightly confused from your description of what is happening.  Here's my understanding
of what should be happening:
> 
> When you have a factory component, then a ComponentFactory service instance is registered
for it whenever the references are satisfied.  I think if you have an optional static reference
the ComponentFactory service will be unregistered and reregistered.
> 
> If in addition the component exposes one or more service interfaces, then whenever you
create an instance with component factory.newInstance(props) a service will be registered
exposing the component instance.  As soon as one of the references causes the instance to
need to be deactivated, such as an optional static reference going away, then the service
is unregistered and the instance deactivated and disposed of.  If you want it back, you have
to call newInstance again.
> 
> -----
> Is this what you are seeing?  If not, how do you know something else is happening?
> 
> -----
> This is remarkably inconvenient since there's no notification from DS that the reference
has disappeared and you need to call newInstance again.  I'm planning to implement in felix
ds a non-spec style of factory component where calling newInstance is pretty much equivalent
to using config admin with a factory pid, so the component will be "existing" whether or not
all the references are present at any particular time, and the instance will be created and
dropped depending on the reference availability.  Also you'll be able to modify the config
of one of these.
> 
> Meanwhile what I would recommend is writing a ManagedServiceFactory that accepts the
factory-pid (pid1) configurations, adds the extra config properties, and creates a new factory-pid
(pid2) configuration with the modified properties. The MSF would be registered under pid1,
and your DS component use pid2.
> 
> thanks!
> david jencks
> 
> 
> On Dec 17, 2013, at 1:35 PM, "Humeniuk, David P" <David.Humeniuk@udri.udayton.edu>
wrote:
> 
>> The component does provide a service and I see that it got registered again, that's
what I was using to assume the instance was re-created.  Perhaps that is why the component
is re-created?  The provided service is not for the needed interface for the consumer though
so I would have to provide a different/another service.
>> 
>> I'm aware of using config admin and factory pids and I'm using that in a way with
these components, but more like a wrapper as I need to add certain properties to all components
of this type.  Are you saying the life cycle is different for these and the DS runtime would
ignore the static policy for the service reference?
>> 
>> Thanks,
>> Dave
>> 
>> -----Original Message-----
>> From: David Jencks [mailto:david_jencks@yahoo.com] 
>> Sent: Tuesday, December 17, 2013 3:45 PM
>> To: users@felix.apache.org
>> Subject: Re: uses ComponentInstances as part of the Declarative Services specification
>> 
>> There is no external notification that the instance has been disposed of.  Assuming
your component has a disposed method, that will get called and you can notify users yourself.
 But I would definitely recommend using a Service instead.
>> 
>> I'm very surprised that an instance obtained from a ComponentFactory is getting recreate
automatically when a static reference becomes unavailable.  I would expect you'd have to create
the new instance yourself.  Are you sure this is what's happening?
>> 
>> Are you aware of how to use config admin with factory pids to create multiple instances
of a component?  This may not be documented all that well but that generally provides component
life cycles that I find more useful.
>> 
>> thanks
>> david jencks
>> 
>> On Dec 17, 2013, at 12:32 PM, "Humeniuk, David P" <David.Humeniuk@udri.udayton.edu>
wrote:
>> 
>>> We've been using ComponentFactory's and ComponentInstances in our software for
a while when we have a component that we need multiple instances.  However, I've noticed that
if a component has an optional, static reference, the component will be disposed and activated
automatically when the service referenced comes and goes (which is not too surprising based
on the meaning of static) meaning the previous instance is no longer valid.
>>> 
>>> The question is, if I have something that uses that instance, how is it supposed
to know about the replaced instance.  I'm guessing that the component instance object should
not be used in this case and I should instead try have the component provide a service and
use the service reference instead??  Is that what is expected or is there some way to be notified
about an updated component instance?
>>> 
>>> Thanks,
>>> Dave Humeniuk
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
> 


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