Re: SCR : Unsatisfied ComponentFactory

[Dave Smith]

I have read over the spec and I would suggest it is unclear if we should be
returning the factory instance or the instances that the factory created.
Either way knowing why a factory is not started is useful and should be
somehow worked into the spec. Right now I had to hack around the limitation
and I am manually checking if the required services are available , not
ideal but it works.


Dave

On Fri, Mar 31, 2017 at 5:28 PM, David Jencks 
wrote:

>
> > On Mar 31, 2017, at 2:20 PM, Dave Smith  wrote:
> >
> > The model controls the UI. When a service becomes unavailable the
> > deactivate is called which then tells the UI that is is not available. In
> > reality this never happens , so it is not an issue.
>
> it might be here :-)
>
> >
> > I would suggest then there is an issue. We should be able to find out why
> > factory components do not resolve , no?
>
> I really want the scr command to be based off of scr runtime. I couldn’t
> think of a plausible way to show the status of the component factory itself
> when this was being specced. You are welcome to take this up with the EG
> :-).
>
> One thing that ought to show the reason is to make all the references
> optional and then in your supplied configuration set the minimum
> cardinality to 1, making them required in the component instances.  So for
> a reference named Foo you’d have Foo.cardinality.minimum=1.  As long as the
> factory component is enabled the ComponentFactory service will be
> registered and if you can’t create an instance you might be able to figure
> out why.
>
> david jencks
>
> >
> > Dave
> >
> > On Fri, Mar 31, 2017 at 5:12 PM, David Jencks 
> > wrote:
> >
> >>
> >>> On Mar 31, 2017, at 1:02 PM, David Jencks 
> >> wrote:
> >>>
> 
>  On Mar 31, 2017, at 11:03 AM, Dave Smith  >> > wrote:
> 
>  See below
> 
>  On Fri, Mar 31, 2017 at 1:51 PM, David Jencks <
> david.a.jen...@gmail.com
> >> >
>  wrote:
> 
> > I think scr:info shows you instances of the factory component you’ve
> > created with newInstance on the ComponentFactory service.  If you
> list
> > services do you see the ComponentFactory service registered from your
> > bundle?
> >
> 
>  No. In the case of a standard service you always get a service pid
>  regardless if the component resolves or not. Thus src:info  will
> >> tell
>  you what is not resolved. In the case of ComponentFactory if it
> >> resolves it
>  gets a PID that you can then get details on otherwise you have to give
> >> it
>  the full name and all this gives you is CompoentInfo but not it's
> state.
> >>>
> >>> I’m not quite sure what you mean and I don’t think you answered my
> >> question about what listing services (not using scr, just by bundle)
> >> shows.  Reviewing the code this from ComponentFactoryImpl makes me think
> >> that the component descriptions
> >>
> >> Apparently I’m not yet awake…. component configurations of course.
> >>
> >>> shown are those created by newInstance, not including one for the
> >> component factory itself:
> >>>
> >>>@Override
> >>>public void getComponentManagers(List
> >> cms)
> >>>{
> >>>synchronized (m_componentInstances)
> >>>{
> >>>cms.addAll(m_componentInstances.keySet());
> >>>}
> >>>}
> >>>
> >>> So I continue to think the scr command won’t tell you much about the
> >> component factory service itself.
> 
> 
> >
> > On a separate note, Ive never seen a plausible use of a factory
> >> component
> > with references, so I’d be interested to see some info about a
> >> situation in
> > which this is a suitable approach.
> >
> 
>  Legacy UI code that follows a Presentation Model style . It holds the
> >> state
>  plus change listeners that call services. Thus the UI looks up the
> >> factory
>  and creates an instance to hold state and run actions (Sort of like a
>  Stateful Session bean , remember those?)
> >>>
> >>> What happens to the UI when one of the referenced services disappears?
> >> Have you found a way to detect this?
> >>
> >> Not being able to find a solution to this has led me to either create
> >> factory configurations or use the felix persistent factory components
> >> extension I wrote to try to make the lifecycle more usable.
> >>
> >> david jencks
> >>
> >>>
> >>> thanks
> >>> david jencks
> >>>
> 
>  Dave
> 
> 
> 
> >
> > thanks
> > david jencks
> >
> >> On Mar 31, 2017, at 8:46 AM, Dave Smith  >> > wrote:
> >>
> >> No, It still has to resolve to know if it is available to activate
> >> and
> >> then register a facade.  Otherwise non DS services that 

Re: SCR : Unsatisfied ComponentFactory

[David Jencks]

> On Mar 31, 2017, at 2:20 PM, Dave Smith  wrote:
> 
> The model controls the UI. When a service becomes unavailable the
> deactivate is called which then tells the UI that is is not available. In
> reality this never happens , so it is not an issue.

it might be here :-)

> 
> I would suggest then there is an issue. We should be able to find out why
> factory components do not resolve , no?

I really want the scr command to be based off of scr runtime. I couldn’t think 
of a plausible way to show the status of the component factory itself when this 
was being specced. You are welcome to take this up with the EG :-).

One thing that ought to show the reason is to make all the references optional 
and then in your supplied configuration set the minimum cardinality to 1, 
making them required in the component instances.  So for a reference named Foo 
you’d have Foo.cardinality.minimum=1.  As long as the factory component is 
enabled the ComponentFactory service will be registered and if you can’t create 
an instance you might be able to figure out why.

david jencks

> 
> Dave
> 
> On Fri, Mar 31, 2017 at 5:12 PM, David Jencks 
> wrote:
> 
>> 
>>> On Mar 31, 2017, at 1:02 PM, David Jencks 
>> wrote:
>>> 
 
 On Mar 31, 2017, at 11:03 AM, Dave Smith > > wrote:
 
 See below
 
 On Fri, Mar 31, 2017 at 1:51 PM, David Jencks > >
 wrote:
 
> I think scr:info shows you instances of the factory component you’ve
> created with newInstance on the ComponentFactory service.  If you list
> services do you see the ComponentFactory service registered from your
> bundle?
> 
 
 No. In the case of a standard service you always get a service pid
 regardless if the component resolves or not. Thus src:info  will
>> tell
 you what is not resolved. In the case of ComponentFactory if it
>> resolves it
 gets a PID that you can then get details on otherwise you have to give
>> it
 the full name and all this gives you is CompoentInfo but not it's state.
>>> 
>>> I’m not quite sure what you mean and I don’t think you answered my
>> question about what listing services (not using scr, just by bundle)
>> shows.  Reviewing the code this from ComponentFactoryImpl makes me think
>> that the component descriptions
>> 
>> Apparently I’m not yet awake…. component configurations of course.
>> 
>>> shown are those created by newInstance, not including one for the
>> component factory itself:
>>> 
>>>@Override
>>>public void getComponentManagers(List
>> cms)
>>>{
>>>synchronized (m_componentInstances)
>>>{
>>>cms.addAll(m_componentInstances.keySet());
>>>}
>>>}
>>> 
>>> So I continue to think the scr command won’t tell you much about the
>> component factory service itself.
 
 
> 
> On a separate note, Ive never seen a plausible use of a factory
>> component
> with references, so I’d be interested to see some info about a
>> situation in
> which this is a suitable approach.
> 
 
 Legacy UI code that follows a Presentation Model style . It holds the
>> state
 plus change listeners that call services. Thus the UI looks up the
>> factory
 and creates an instance to hold state and run actions (Sort of like a
 Stateful Session bean , remember those?)
>>> 
>>> What happens to the UI when one of the referenced services disappears?
>> Have you found a way to detect this?
>> 
>> Not being able to find a solution to this has led me to either create
>> factory configurations or use the felix persistent factory components
>> extension I wrote to try to make the lifecycle more usable.
>> 
>> david jencks
>> 
>>> 
>>> thanks
>>> david jencks
>>> 
 
 Dave
 
 
 
> 
> thanks
> david jencks
> 
>> On Mar 31, 2017, at 8:46 AM, Dave Smith > > wrote:
>> 
>> No, It still has to resolve to know if it is available to activate
>> and
>> then register a facade.  Otherwise non DS services that might use it
> would
>> not see it.
>> 
>> Dave
>> 
>> On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge <
>> raymond.a...@liferay.com 
>> 
>> wrote:
>> 
>>> On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith > >
>>> wrote:
>>> 
 It is ugly (long story)
 
 scr:info com.candata.b3.client.bbx.TRACK01
 *** Bundle: com.candata.b3.client.jnj (7)
 Component Description:
 Name: com.candata.b3.client.bbx.TRACK01
 Implementation Class: com.candata.b3.client.bbx.TRACK01
 Default State: enabled
 

Re: SCR : Unsatisfied ComponentFactory

[David Jencks]

> On Mar 31, 2017, at 1:02 PM, David Jencks  wrote:
> 
>> 
>> On Mar 31, 2017, at 11:03 AM, Dave Smith > > wrote:
>> 
>> See below
>> 
>> On Fri, Mar 31, 2017 at 1:51 PM, David Jencks > >
>> wrote:
>> 
>>> I think scr:info shows you instances of the factory component you’ve
>>> created with newInstance on the ComponentFactory service.  If you list
>>> services do you see the ComponentFactory service registered from your
>>> bundle?
>>> 
>> 
>> No. In the case of a standard service you always get a service pid
>> regardless if the component resolves or not. Thus src:info  will tell
>> you what is not resolved. In the case of ComponentFactory if it resolves it
>> gets a PID that you can then get details on otherwise you have to give it
>> the full name and all this gives you is CompoentInfo but not it's state.
> 
> I’m not quite sure what you mean and I don’t think you answered my question 
> about what listing services (not using scr, just by bundle) shows.  Reviewing 
> the code this from ComponentFactoryImpl makes me think that the component 
> descriptions

Apparently I’m not yet awake…. component configurations of course.

> shown are those created by newInstance, not including one for the component 
> factory itself:
> 
> @Override
> public void getComponentManagers(List cms)
> {
> synchronized (m_componentInstances)
> {
> cms.addAll(m_componentInstances.keySet());
> }
> }
> 
> So I continue to think the scr command won’t tell you much about the 
> component factory service itself.
>> 
>> 
>>> 
>>> On a separate note, Ive never seen a plausible use of a factory component
>>> with references, so I’d be interested to see some info about a situation in
>>> which this is a suitable approach.
>>> 
>> 
>> Legacy UI code that follows a Presentation Model style . It holds the state
>> plus change listeners that call services. Thus the UI looks up the factory
>> and creates an instance to hold state and run actions (Sort of like a
>> Stateful Session bean , remember those?)
> 
> What happens to the UI when one of the referenced services disappears?  Have 
> you found a way to detect this?

Not being able to find a solution to this has led me to either create factory 
configurations or use the felix persistent factory components extension I wrote 
to try to make the lifecycle more usable.

david jencks

> 
> thanks
> david jencks
> 
>> 
>> Dave
>> 
>> 
>> 
>>> 
>>> thanks
>>> david jencks
>>> 
 On Mar 31, 2017, at 8:46 AM, Dave Smith > wrote:
 
 No, It still has to resolve to know if it is available to activate  and
 then register a facade.  Otherwise non DS services that might use it
>>> would
 not see it.
 
 Dave
 
 On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge 
 
 wrote:
 
> On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith  >
> wrote:
> 
>> It is ugly (long story)
>> 
>> scr:info com.candata.b3.client.bbx.TRACK01
>> *** Bundle: com.candata.b3.client.jnj (7)
>> Component Description:
>> Name: com.candata.b3.client.bbx.TRACK01
>> Implementation Class: com.candata.b3.client.bbx.TRACK01
>> Default State: enabled
>> Activation: delayed
>> 
> 
> This is significant! It means the component is lazily activated!
> Effectively this says that the component won't do anything (such as
> activate) until some other actor requests the service from the service
> registry.
> 
> Could that be your issue?
> 
> - Ray
> 
> 
>> Configuration Policy: optional
>> Activate Method: activate
>> Deactivate Method: deactivate
>> Modified Method: -
>> Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
>> Factory: com.candata.b3.client.bbx.TRACK01
>> Services:
>>   com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
>> Service Scope: singleton
>> Reference: B313AFactory
>>   Interface Name: org.osgi.service.component.ComponentFactory
>>   Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
>>   Cardinality: 1..1
>>   Policy: static
>>   Policy option: reluctant
>>   Reference Scope: bundle
>> Reference: B3LogDAO
>>   Interface Name: com.candata.b3.common.interfaces.B3LogDAO
>>   Cardinality: 1..1
>>   Policy: static
>>   Policy option: reluctant
>>   Reference Scope: bundle
>> Reference: BbxContext
>>   Interface Name: com.candata.bbx.client.interp.interfaces.BbxContext
>>   Cardinality: 1..1
>>   Policy: static
>>   Policy option: reluctant
>>   Reference Scope: 

Re: SCR : Unsatisfied ComponentFactory

[David Jencks]

> On Mar 31, 2017, at 11:03 AM, Dave Smith  wrote:
> 
> See below
> 
> On Fri, Mar 31, 2017 at 1:51 PM, David Jencks  >
> wrote:
> 
>> I think scr:info shows you instances of the factory component you’ve
>> created with newInstance on the ComponentFactory service.  If you list
>> services do you see the ComponentFactory service registered from your
>> bundle?
>> 
> 
> No. In the case of a standard service you always get a service pid
> regardless if the component resolves or not. Thus src:info  will tell
> you what is not resolved. In the case of ComponentFactory if it resolves it
> gets a PID that you can then get details on otherwise you have to give it
> the full name and all this gives you is CompoentInfo but not it's state.

I’m not quite sure what you mean and I don’t think you answered my question 
about what listing services (not using scr, just by bundle) shows.  Reviewing 
the code this from ComponentFactoryImpl makes me think that the component 
descriptions shown are those created by newInstance, not including one for the 
component factory itself:

@Override
public void getComponentManagers(List cms)
{
synchronized (m_componentInstances)
{
cms.addAll(m_componentInstances.keySet());
}
}

So I continue to think the scr command won’t tell you much about the component 
factory service itself.
> 
> 
>> 
>> On a separate note, Ive never seen a plausible use of a factory component
>> with references, so I’d be interested to see some info about a situation in
>> which this is a suitable approach.
>> 
> 
> Legacy UI code that follows a Presentation Model style . It holds the state
> plus change listeners that call services. Thus the UI looks up the factory
> and creates an instance to hold state and run actions (Sort of like a
> Stateful Session bean , remember those?)

What happens to the UI when one of the referenced services disappears?  Have 
you found a way to detect this?

thanks
david jencks

> 
> Dave
> 
> 
> 
>> 
>> thanks
>> david jencks
>> 
>>> On Mar 31, 2017, at 8:46 AM, Dave Smith  wrote:
>>> 
>>> No, It still has to resolve to know if it is available to activate  and
>>> then register a facade.  Otherwise non DS services that might use it
>> would
>>> not see it.
>>> 
>>> Dave
>>> 
>>> On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge >> 
>>> wrote:
>>> 
 On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith 
 wrote:
 
> It is ugly (long story)
> 
> scr:info com.candata.b3.client.bbx.TRACK01
> *** Bundle: com.candata.b3.client.jnj (7)
> Component Description:
> Name: com.candata.b3.client.bbx.TRACK01
> Implementation Class: com.candata.b3.client.bbx.TRACK01
> Default State: enabled
> Activation: delayed
> 
 
 This is significant! It means the component is lazily activated!
 Effectively this says that the component won't do anything (such as
 activate) until some other actor requests the service from the service
 registry.
 
 Could that be your issue?
 
 - Ray
 
 
> Configuration Policy: optional
> Activate Method: activate
> Deactivate Method: deactivate
> Modified Method: -
> Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
> Factory: com.candata.b3.client.bbx.TRACK01
> Services:
>   com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
> Service Scope: singleton
> Reference: B313AFactory
>   Interface Name: org.osgi.service.component.ComponentFactory
>   Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
>   Cardinality: 1..1
>   Policy: static
>   Policy option: reluctant
>   Reference Scope: bundle
> Reference: B3LogDAO
>   Interface Name: com.candata.b3.common.interfaces.B3LogDAO
>   Cardinality: 1..1
>   Policy: static
>   Policy option: reluctant
>   Reference Scope: bundle
> Reference: BbxContext
>   Interface Name: com.candata.bbx.client.interp.interfaces.BbxContext
>   Cardinality: 1..1
>   Policy: static
>   Policy option: reluctant
>   Reference Scope: bundle
> Reference: CCI01AFactory
>   Interface Name: org.osgi.service.component.ComponentFactory
>   Target Filter: (component.factory=com.candata.b3.client.bbx.CCI01A)
>   Cardinality: 1..1
>   Policy: static
>   Policy option: reluctant
>   Reference Scope: bundle
> Reference: CCIImporterPMFactory
>   Interface Name: org.osgi.service.component.ComponentFactory
>   Target Filter: (component.factory=com.candata.custom.fyke.client.
> model.CCIImporterPM)
>   Cardinality: 0..1
>   Policy: static
>   Policy option: reluctant
>   Reference Scope: bundle
> Reference: CarrierDAO
>   Interface Name: 

Re: SCR : Unsatisfied ComponentFactory

[Dave Smith]

See below

On Fri, Mar 31, 2017 at 1:51 PM, David Jencks 
wrote:

> I think scr:info shows you instances of the factory component you’ve
> created with newInstance on the ComponentFactory service.  If you list
> services do you see the ComponentFactory service registered from your
> bundle?
>

No. In the case of a standard service you always get a service pid
regardless if the component resolves or not. Thus src:info  will tell
you what is not resolved. In the case of ComponentFactory if it resolves it
gets a PID that you can then get details on otherwise you have to give it
the full name and all this gives you is CompoentInfo but not it's state.


>
> On a separate note, Ive never seen a plausible use of a factory component
> with references, so I’d be interested to see some info about a situation in
> which this is a suitable approach.
>

Legacy UI code that follows a Presentation Model style . It holds the state
plus change listeners that call services. Thus the UI looks up the factory
and creates an instance to hold state and run actions (Sort of like a
Stateful Session bean , remember those?)

Dave



>
> thanks
> david jencks
>
> > On Mar 31, 2017, at 8:46 AM, Dave Smith  wrote:
> >
> > No, It still has to resolve to know if it is available to activate  and
> > then register a facade.  Otherwise non DS services that might use it
> would
> > not see it.
> >
> > Dave
> >
> > On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge  >
> > wrote:
> >
> >> On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith 
> >> wrote:
> >>
> >>> It is ugly (long story)
> >>>
> >>> scr:info com.candata.b3.client.bbx.TRACK01
> >>> *** Bundle: com.candata.b3.client.jnj (7)
> >>> Component Description:
> >>>  Name: com.candata.b3.client.bbx.TRACK01
> >>>  Implementation Class: com.candata.b3.client.bbx.TRACK01
> >>>  Default State: enabled
> >>>  Activation: delayed
> >>>
> >>
> >> This is significant! It means the component is lazily activated!
> >> Effectively this says that the component won't do anything (such as
> >> activate) until some other actor requests the service from the service
> >> registry.
> >>
> >> Could that be your issue?
> >>
> >> - Ray
> >>
> >>
> >>>  Configuration Policy: optional
> >>>  Activate Method: activate
> >>>  Deactivate Method: deactivate
> >>>  Modified Method: -
> >>>  Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
> >>>  Factory: com.candata.b3.client.bbx.TRACK01
> >>>  Services:
> >>>com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
> >>>  Service Scope: singleton
> >>>  Reference: B313AFactory
> >>>Interface Name: org.osgi.service.component.ComponentFactory
> >>>Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: B3LogDAO
> >>>Interface Name: com.candata.b3.common.interfaces.B3LogDAO
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: BbxContext
> >>>Interface Name: com.candata.bbx.client.interp.interfaces.BbxContext
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: CCI01AFactory
> >>>Interface Name: org.osgi.service.component.ComponentFactory
> >>>Target Filter: (component.factory=com.candata.b3.client.bbx.CCI01A)
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: CCIImporterPMFactory
> >>>Interface Name: org.osgi.service.component.ComponentFactory
> >>>Target Filter: (component.factory=com.candata.custom.fyke.client.
> >>> model.CCIImporterPM)
> >>>Cardinality: 0..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: CarrierDAO
> >>>Interface Name: com.candata.comm.cbsa.common.interfaces.CarrierDAO
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: CompanyInfoService
> >>>Interface Name: com.candata.broker.util.common.services.
> >>> CompanyInfoService
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: CustomerDAO
> >>>Interface Name: com.candata.customer.common.interfaces.CustomerDAO
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: CustomsConfigurationService
> >>>Interface Name: com.candata.b3.client.services.
> >>> CustomsConfigurationService
> >>>Cardinality: 1..1
> >>>Policy: static
> >>>Policy option: reluctant
> >>>Reference Scope: bundle
> >>>  Reference: DisplayThreadService
> >>>Interface Name: 

Re: SCR : Unsatisfied ComponentFactory

[Dave Smith]

No, It still has to resolve to know if it is available to activate  and
then register a facade.  Otherwise non DS services that might use it would
not see it.

Dave

On Fri, Mar 31, 2017 at 11:41 AM, Raymond Auge 
wrote:

> On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith 
> wrote:
>
> > It is ugly (long story)
> >
> > scr:info com.candata.b3.client.bbx.TRACK01
> > *** Bundle: com.candata.b3.client.jnj (7)
> > Component Description:
> >   Name: com.candata.b3.client.bbx.TRACK01
> >   Implementation Class: com.candata.b3.client.bbx.TRACK01
> >   Default State: enabled
> >   Activation: delayed
> >
>
> This is significant! It means the component is lazily activated!
> Effectively this says that the component won't do anything (such as
> activate) until some other actor requests the service from the service
> registry.
>
> Could that be your issue?
>
> - Ray
>
>
> >   Configuration Policy: optional
> >   Activate Method: activate
> >   Deactivate Method: deactivate
> >   Modified Method: -
> >   Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
> >   Factory: com.candata.b3.client.bbx.TRACK01
> >   Services:
> > com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
> >   Service Scope: singleton
> >   Reference: B313AFactory
> > Interface Name: org.osgi.service.component.ComponentFactory
> > Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: B3LogDAO
> > Interface Name: com.candata.b3.common.interfaces.B3LogDAO
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: BbxContext
> > Interface Name: com.candata.bbx.client.interp.interfaces.BbxContext
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: CCI01AFactory
> > Interface Name: org.osgi.service.component.ComponentFactory
> > Target Filter: (component.factory=com.candata.b3.client.bbx.CCI01A)
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: CCIImporterPMFactory
> > Interface Name: org.osgi.service.component.ComponentFactory
> > Target Filter: (component.factory=com.candata.custom.fyke.client.
> > model.CCIImporterPM)
> > Cardinality: 0..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: CarrierDAO
> > Interface Name: com.candata.comm.cbsa.common.interfaces.CarrierDAO
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: CompanyInfoService
> > Interface Name: com.candata.broker.util.common.services.
> > CompanyInfoService
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: CustomerDAO
> > Interface Name: com.candata.customer.common.interfaces.CustomerDAO
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: CustomsConfigurationService
> > Interface Name: com.candata.b3.client.services.
> > CustomsConfigurationService
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: DisplayThreadService
> > Interface Name: com.candata.swt.services.DisplayThreadService
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: EntryStatusDAO
> > Interface Name: com.candata.b3.common.interfaces.EntryStatusDAO
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: ErrorHandlingService
> > Interface Name: com.candata.gui.services.ErrorHandlingService
> > Cardinality: 1..1
> > Policy: static
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: INV01Service
> > Interface Name: com.candata.bbx.client.services.INV01Service
> > Cardinality: 0..1
> > Policy: dynamic
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: INV11BService
> > Interface Name: com.candata.bbx.client.services.INV11BService
> > Cardinality: 0..1
> > Policy: dynamic
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: IOpenItems
> > Interface Name: com.candata.core.common.interfaces.invoicing.
> > IOpenItems
> > Cardinality: 0..1
> > Policy: dynamic
> > Policy option: reluctant
> > Reference Scope: bundle
> >   Reference: ITrackCharges
> > Interface Name: com.candata.core.common.interfaces.invoicing.
> > ITrackCharges
> > Cardinality: 0..1
> > Policy: dynamic

Re: SCR : Unsatisfied ComponentFactory

[Raymond Auge]

On Fri, Mar 31, 2017 at 11:22 AM, Dave Smith  wrote:

> It is ugly (long story)
>
> scr:info com.candata.b3.client.bbx.TRACK01
> *** Bundle: com.candata.b3.client.jnj (7)
> Component Description:
>   Name: com.candata.b3.client.bbx.TRACK01
>   Implementation Class: com.candata.b3.client.bbx.TRACK01
>   Default State: enabled
>   Activation: delayed
>

This is significant! It means the component is lazily activated!
Effectively this says that the component won't do anything (such as
activate) until some other actor requests the service from the service
registry.

Could that be your issue?

- Ray


>   Configuration Policy: optional
>   Activate Method: activate
>   Deactivate Method: deactivate
>   Modified Method: -
>   Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
>   Factory: com.candata.b3.client.bbx.TRACK01
>   Services:
> com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
>   Service Scope: singleton
>   Reference: B313AFactory
> Interface Name: org.osgi.service.component.ComponentFactory
> Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: B3LogDAO
> Interface Name: com.candata.b3.common.interfaces.B3LogDAO
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: BbxContext
> Interface Name: com.candata.bbx.client.interp.interfaces.BbxContext
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: CCI01AFactory
> Interface Name: org.osgi.service.component.ComponentFactory
> Target Filter: (component.factory=com.candata.b3.client.bbx.CCI01A)
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: CCIImporterPMFactory
> Interface Name: org.osgi.service.component.ComponentFactory
> Target Filter: (component.factory=com.candata.custom.fyke.client.
> model.CCIImporterPM)
> Cardinality: 0..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: CarrierDAO
> Interface Name: com.candata.comm.cbsa.common.interfaces.CarrierDAO
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: CompanyInfoService
> Interface Name: com.candata.broker.util.common.services.
> CompanyInfoService
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: CustomerDAO
> Interface Name: com.candata.customer.common.interfaces.CustomerDAO
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: CustomsConfigurationService
> Interface Name: com.candata.b3.client.services.
> CustomsConfigurationService
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: DisplayThreadService
> Interface Name: com.candata.swt.services.DisplayThreadService
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: EntryStatusDAO
> Interface Name: com.candata.b3.common.interfaces.EntryStatusDAO
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: ErrorHandlingService
> Interface Name: com.candata.gui.services.ErrorHandlingService
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: INV01Service
> Interface Name: com.candata.bbx.client.services.INV01Service
> Cardinality: 0..1
> Policy: dynamic
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: INV11BService
> Interface Name: com.candata.bbx.client.services.INV11BService
> Cardinality: 0..1
> Policy: dynamic
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: IOpenItems
> Interface Name: com.candata.core.common.interfaces.invoicing.
> IOpenItems
> Cardinality: 0..1
> Policy: dynamic
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: ITrackCharges
> Interface Name: com.candata.core.common.interfaces.invoicing.
> ITrackCharges
> Cardinality: 0..1
> Policy: dynamic
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: InvoiceFindResultService
> Interface Name: com.candata.inv.api.common.services.
> InvoiceFindResultService
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: InvoiceSettingsService
> Interface Name: com.candata.inv.api.client.services.
> InvoiceSettingsService
> Cardinality: 0..1
> Policy: dynamic
> Policy option: reluctant
> Reference 

Re: SCR : Unsatisfied ComponentFactory

[Dave Smith]

It is ugly (long story)

scr:info com.candata.b3.client.bbx.TRACK01
*** Bundle: com.candata.b3.client.jnj (7)
Component Description:
  Name: com.candata.b3.client.bbx.TRACK01
  Implementation Class: com.candata.b3.client.bbx.TRACK01
  Default State: enabled
  Activation: delayed
  Configuration Policy: optional
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.candata.b3.client.bbx.TRACK01]
  Factory: com.candata.b3.client.bbx.TRACK01
  Services:
com.candata.bbx.client.interp.interfaces.BbxProgWithArgs
  Service Scope: singleton
  Reference: B313AFactory
Interface Name: org.osgi.service.component.ComponentFactory
Target Filter: (component.factory=com.candata.b3.client.bbx.B313A)
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: B3LogDAO
Interface Name: com.candata.b3.common.interfaces.B3LogDAO
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: BbxContext
Interface Name: com.candata.bbx.client.interp.interfaces.BbxContext
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: CCI01AFactory
Interface Name: org.osgi.service.component.ComponentFactory
Target Filter: (component.factory=com.candata.b3.client.bbx.CCI01A)
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: CCIImporterPMFactory
Interface Name: org.osgi.service.component.ComponentFactory
Target Filter: (component.factory=com.candata.custom.fyke.client.
model.CCIImporterPM)
Cardinality: 0..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: CarrierDAO
Interface Name: com.candata.comm.cbsa.common.interfaces.CarrierDAO
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: CompanyInfoService
Interface Name: com.candata.broker.util.common.services.
CompanyInfoService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: CustomerDAO
Interface Name: com.candata.customer.common.interfaces.CustomerDAO
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: CustomsConfigurationService
Interface Name: com.candata.b3.client.services.
CustomsConfigurationService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: DisplayThreadService
Interface Name: com.candata.swt.services.DisplayThreadService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: EntryStatusDAO
Interface Name: com.candata.b3.common.interfaces.EntryStatusDAO
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: ErrorHandlingService
Interface Name: com.candata.gui.services.ErrorHandlingService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: INV01Service
Interface Name: com.candata.bbx.client.services.INV01Service
Cardinality: 0..1
Policy: dynamic
Policy option: reluctant
Reference Scope: bundle
  Reference: INV11BService
Interface Name: com.candata.bbx.client.services.INV11BService
Cardinality: 0..1
Policy: dynamic
Policy option: reluctant
Reference Scope: bundle
  Reference: IOpenItems
Interface Name: com.candata.core.common.interfaces.invoicing.IOpenItems
Cardinality: 0..1
Policy: dynamic
Policy option: reluctant
Reference Scope: bundle
  Reference: ITrackCharges
Interface Name: com.candata.core.common.interfaces.invoicing.
ITrackCharges
Cardinality: 0..1
Policy: dynamic
Policy option: reluctant
Reference Scope: bundle
  Reference: InvoiceFindResultService
Interface Name: com.candata.inv.api.common.services.
InvoiceFindResultService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: InvoiceSettingsService
Interface Name: com.candata.inv.api.client.services.
InvoiceSettingsService
Cardinality: 0..1
Policy: dynamic
Policy option: reluctant
Reference Scope: bundle
  Reference: Logger
Interface Name: com.candata.core.api.interfaces.Logger
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: Mar03Factory
Interface Name: org.osgi.service.component.ComponentFactory
Target Filter: (component.factory=com.candata.customer.client.bbx.MAR03)
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: Menu13
Interface Name: com.candata.b3.client.bbx.Menu13
Cardinality: 1..1
Policy: static
Policy option: reluctant

Re: SCR : Unsatisfied ComponentFactory

[Raymond Auge]

On Fri, Mar 31, 2017 at 11:13 AM, Dave Smith  wrote:

> com.candata.b3.client.bbx.TRACK01
>

please do

scr:info com.candata.b3.client.bbx.TRACK01



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

Re: SCR : Unsatisfied ComponentFactory

[Dave Smith]

scr:list

gives ..

[   7]   com.candata.b3.client.bbx.TRACK01  enabled

Where 7 is the bundle id.

scr:info com.candata.b3.client.bbx.TRACK01

just lists the services it uses but not if they are resolved. There is no
service id assigned to it

Dave

On Fri, Mar 31, 2017 at 11:06 AM, Raymond Auge 
wrote:

> It might help to show the dump of the scr:info command here so we can try
> to figure out the issue.
>
> Sincerely,
> - Ray
>
> On Fri, Mar 31, 2017 at 10:41 AM, Dave Smith 
> wrote:
>
> > We have some ComponentFactory's that are not starting. However in the
> GOGO
> > shell console and the using the ServiceComponentRuntime there are no
> > unsatisfiedReferences  shown for the factory and the Factories are not
> > registered in the services list
> >
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

Re: SCR : Unsatisfied ComponentFactory

[Raymond Auge]

It might help to show the dump of the scr:info command here so we can try
to figure out the issue.

Sincerely,
- Ray

On Fri, Mar 31, 2017 at 10:41 AM, Dave Smith  wrote:

> We have some ComponentFactory's that are not starting. However in the GOGO
> shell console and the using the ServiceComponentRuntime there are no
> unsatisfiedReferences  shown for the factory and the Factories are not
> registered in the services list
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)