date:20160812

Re: how to enable felix verify the contents of a signed bundle

2016-08-12 Thread Karl Pauls

Hi sid,

see inline:


> after installing , i tried to start it as shown above but its state was
> still shown as Resolved,
> *5|Resolved   |1|Apache Felix Security Provider (2.4.0)|2.4.0*
>

this is ok - the security provider is an extension bundle.


> then i tried to install a sample corrupt jar file which was signed earliar
> using jarsigner tool provided by jdk 6 present on my windows machine. *I
> was
> expecting that this bundle won't install and some security exception would
> appear on the shell.
> But it was installed and a bundleid was allocated successfully as shown
> below:*
> g!
> g! install my_tempered3.jar
> Bundle ID: 6
> g!
>
> please tell , did i get wrong somewhere or missed some step ?
>

How do you know it is corrupt?

regards,

Karl


> Or what are the steps to enable signature verification in felix framework?
>
> i am a newbie here, please someone do share your view points.
>
> Thanks
> sid
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.
> nabble.com/how-to-enable-felix-verify-the-contents-of-
> a-signed-bundle-tp5018089.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>


-- 
Karl Pauls
karlpa...@gmail.com

how to enable felix verify the contents of a signed bundle

2016-08-12 Thread sid19039

Hello All,

I am trying to test that felix first verify the contents of a signed bundle
and then install it if verified successfully. To accomplish this , i
downloaded an org.apache.felix.framework.security bundle i.e
*org.apache.felix.framework.security-2.4.0.jar* which i read, is required to
be installed into felix framework to enable feature of signature
verification of an OSGi bundle.

i then created a *all.policy* file in felix framework home directory(on
windows) containing data as following:
*grant {
 permission java.security.AllPermission;
};*

I then tried to open the felix shell via following command on command
Prompt:
*java -Djava.security.policy=all.policy -Dorg.osgi.framework.security="osgi"
-jar bin/felix.jar*
shell was opened successfully.

I then tried to install the felix framework security bundle as following:

Welcome to Apache Felix Gogo

g!
g!
g! install org.apache.felix.framework.security-2.4.0.jar
Bundle ID: 5
g!
g! start 5
g!

after installing , i tried to start it as shown above but its state was
still shown as Resolved,
*5|Resolved   |1|Apache Felix Security Provider (2.4.0)|2.4.0*

then i tried to install a sample corrupt jar file which was signed earliar
using jarsigner tool provided by jdk 6 present on my windows machine. *I was
expecting that this bundle won't install and some security exception would
appear on the shell.
But it was installed and a bundleid was allocated successfully as shown
below:*
g!
g! install my_tempered3.jar
Bundle ID: 6
g!

please tell , did i get wrong somewhere or missed some step ?
Or what are the steps to enable signature verification in felix framework?

i am a newbie here, please someone do share your view points.

Thanks
sid










--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/how-to-enable-felix-verify-the-contents-of-a-signed-bundle-tp5018089.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Neil Bartlett


> On 12 Aug 2016, at 12:59, Benson Margulies  wrote:
> 
> On Fri, Aug 12, 2016 at 7:54 AM, Karel Haeck  > wrote:
>> 
>> You typically use a serviceTracker in the test bundle to obtain a reference
>> to the component 's service.
>> See http://enroute.osgi.org/tutorial_base/600-testing.html 
>>  for how to do
>> this in bndtools.
>> The service tracker open method will trigger the component's delayed
>> activation
> 
> I didn't realize that the service tracker could interact with DS. Thanks.


This is the great thing about OSGi Services — they enable any framework to 
interact with any other framework. You only need to use DS where it makes 
sense. In other places you might want to use low-level API or even another 
framework like Blueprint.

Okay just kidding, you never want to use Blueprint!! But hopefully you get the 
idea.

Neil

> 
> 
>> 
>> Karel
>> 
>> 
>> On 12/08/2016 13:30, Benson Margulies wrote:
>>> 
>>> Thank you all. Indeed, the component was not 'immediate', and that's
>>> why it wasn't set up.
>>> 
>>> My task of the moment it to add pax-exam tests for some individual
>>> components; in the past, I only tested this stuff with broad
>>> functional tests. This has led me, on this particular occasion,  end
>>> up trying to test this not-immediate component.
>>> 
>>> How do other people create pax-exam tests for @Components that are not
>>> immediate? By adding DS metadata to pax-exam bundles?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> g! scr:info com.basistech.ws.worker.core.Worker
>>> *** Bundle: rosapi-worker-core (59)
>>> Component Description:
>>>   Name: com.basistech.ws.worker.core.Worker
>>>   Implementation Class: com.basistech.ws.worker.core.Worker
>>>   Default State: enabled
>>>   Activation: immediate
>>>   Configuration Policy: ignore
>>>   Activate Method: activate
>>>   Deactivate Method: deactivate
>>>   Modified Method: -
>>>   Configuration Pid: [com.basistech.ws.worker.core.Worker]
>>>   Services:
>>> com.basistech.ws.worker.api.WorkerInterface
>>>   Service Scope: singleton
>>>   Reference: BusService
>>> Interface Name: com.basistech.ws.worker.api.WorkerBusService
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>>   Reference: WorkerComponentServices
>>> Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>>   Reference: WorkerConfiguration
>>> Interface Name:
>>> com.basistech.ws.worker.core.config.WorkerConfiguration
>>> Cardinality: 1..1
>>> Policy: static
>>> Policy option: reluctant
>>> Reference Scope: bundle
>>>   Component Description Properties:
>>>   Component Configuration:
>>> ComponentId: 5
>>> State: active
>>> SatisfiedReference: BusService
>>>   Target: null
>>>   Bound to:39
>>>   Reference Properties:
>>>   component.id = 3
>>>   component.name = com.basistech.ws.worker.bus.impl.BusService
>>>   licensePathname =
>>> 
>>> /Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
>>>   objectClass = [com.basistech.ws.worker.api.WorkerBusService]
>>>   service.bundleid = 24
>>>   service.id = 39
>>>   service.pid = com.basistech.ws.bus
>>>   service.scope = bundle
>>> SatisfiedReference: WorkerComponentServices
>>>   Target: null
>>>   Bound to:56
>>>   Reference Properties:
>>>   objectClass =
>>> [com.basistech.ws.worker.core.WorkerComponentServices]
>>>   service.bundleid = 59
>>>   service.id = 56
>>>   service.scope = singleton
>>> SatisfiedReference: WorkerConfiguration
>>>   Target: null
>>>   Bound to:40
>>>   Reference Properties:
>>>   component.id = 6
>>>   component.name =
>>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>>   configurationFilePathname =
>>> 
>>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>>>   endpointsPathname =
>>> 
>>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>>>   native-root =
>>> 
>>> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
>>>   objectClass =
>>> [com.basistech.ws.worker.core.config.WorkerConfiguration]
>>>   service.bundleid = 59
>>>   service.id = 40
>>>   service.pid = com.basistech.ws.worker
>>>   service.scope = bundle
>>>   subst = tsbus
>>> Component Configuration Properties:
>>> component.id = 5
>>> component.name = com.basistech.ws.worker.core.Worker
>>> 
>>> On Fri, Aug 12, 2016 at 6:05 AM, Ferry Huberts  wrote:
 
 
 On 12/0

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Benson Margulies

On Fri, Aug 12, 2016 at 7:54 AM, Karel Haeck  wrote:
>
> You typically use a serviceTracker in the test bundle to obtain a reference
> to the component 's service.
> See http://enroute.osgi.org/tutorial_base/600-testing.html for how to do
> this in bndtools.
> The service tracker open method will trigger the component's delayed
> activation

I didn't realize that the service tracker could interact with DS. Thanks.


>
> Karel
>
>
> On 12/08/2016 13:30, Benson Margulies wrote:
>>
>> Thank you all. Indeed, the component was not 'immediate', and that's
>> why it wasn't set up.
>>
>> My task of the moment it to add pax-exam tests for some individual
>> components; in the past, I only tested this stuff with broad
>> functional tests. This has led me, on this particular occasion,  end
>> up trying to test this not-immediate component.
>>
>> How do other people create pax-exam tests for @Components that are not
>> immediate? By adding DS metadata to pax-exam bundles?
>>
>>
>>
>>
>>
>>
>> g! scr:info com.basistech.ws.worker.core.Worker
>> *** Bundle: rosapi-worker-core (59)
>> Component Description:
>>Name: com.basistech.ws.worker.core.Worker
>>Implementation Class: com.basistech.ws.worker.core.Worker
>>Default State: enabled
>>Activation: immediate
>>Configuration Policy: ignore
>>Activate Method: activate
>>Deactivate Method: deactivate
>>Modified Method: -
>>Configuration Pid: [com.basistech.ws.worker.core.Worker]
>>Services:
>>  com.basistech.ws.worker.api.WorkerInterface
>>Service Scope: singleton
>>Reference: BusService
>>  Interface Name: com.basistech.ws.worker.api.WorkerBusService
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>>Reference: WorkerComponentServices
>>  Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>>Reference: WorkerConfiguration
>>  Interface Name:
>> com.basistech.ws.worker.core.config.WorkerConfiguration
>>  Cardinality: 1..1
>>  Policy: static
>>  Policy option: reluctant
>>  Reference Scope: bundle
>>Component Description Properties:
>>Component Configuration:
>>  ComponentId: 5
>>  State: active
>>  SatisfiedReference: BusService
>>Target: null
>>Bound to:39
>>Reference Properties:
>>component.id = 3
>>component.name = com.basistech.ws.worker.bus.impl.BusService
>>licensePathname =
>>
>> /Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
>>objectClass = [com.basistech.ws.worker.api.WorkerBusService]
>>service.bundleid = 24
>>service.id = 39
>>service.pid = com.basistech.ws.bus
>>service.scope = bundle
>>  SatisfiedReference: WorkerComponentServices
>>Target: null
>>Bound to:56
>>Reference Properties:
>>objectClass =
>> [com.basistech.ws.worker.core.WorkerComponentServices]
>>service.bundleid = 59
>>service.id = 56
>>service.scope = singleton
>>  SatisfiedReference: WorkerConfiguration
>>Target: null
>>Bound to:40
>>Reference Properties:
>>component.id = 6
>>component.name =
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>configurationFilePathname =
>>
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>>endpointsPathname =
>>
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>>native-root =
>>
>> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
>>objectClass =
>> [com.basistech.ws.worker.core.config.WorkerConfiguration]
>>service.bundleid = 59
>>service.id = 40
>>service.pid = com.basistech.ws.worker
>>service.scope = bundle
>>subst = tsbus
>>  Component Configuration Properties:
>>  component.id = 5
>>  component.name = com.basistech.ws.worker.core.Worker
>>
>> On Fri, Aug 12, 2016 at 6:05 AM, Ferry Huberts  wrote:
>>>
>>>
>>> On 12/08/16 12:02, Carsten Ziegeler wrote:
>
> Thanks Carsten, that was my expectation but I was waiting for the
> “inspect cap service” output to confirm.
>
> One thing that can be quite confusing is that the service
> references, with cardinality of 1..1, are described as both
> satisfied and unbound. This sounds like a contradiction until you
> realise the component has not yet been instantiated. I assume that
> SCR at this point does know which services it *will* bind when the
> component is activated… maybe these could be shown here?
>

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Karel Haeck



You typically use a serviceTracker in the test bundle to obtain a 
reference to the component 's service.
See http://enroute.osgi.org/tutorial_base/600-testing.html for how to do 
this in bndtools.
The service tracker open method will trigger the component's delayed 
activation


Karel

On 12/08/2016 13:30, Benson Margulies wrote:

Thank you all. Indeed, the component was not 'immediate', and that's
why it wasn't set up.

My task of the moment it to add pax-exam tests for some individual
components; in the past, I only tested this stuff with broad
functional tests. This has led me, on this particular occasion,  end
up trying to test this not-immediate component.

How do other people create pax-exam tests for @Components that are not
immediate? By adding DS metadata to pax-exam bundles?






g! scr:info com.basistech.ws.worker.core.Worker
*** Bundle: rosapi-worker-core (59)
Component Description:
   Name: com.basistech.ws.worker.core.Worker
   Implementation Class: com.basistech.ws.worker.core.Worker
   Default State: enabled
   Activation: immediate
   Configuration Policy: ignore
   Activate Method: activate
   Deactivate Method: deactivate
   Modified Method: -
   Configuration Pid: [com.basistech.ws.worker.core.Worker]
   Services:
 com.basistech.ws.worker.api.WorkerInterface
   Service Scope: singleton
   Reference: BusService
 Interface Name: com.basistech.ws.worker.api.WorkerBusService
 Cardinality: 1..1
 Policy: static
 Policy option: reluctant
 Reference Scope: bundle
   Reference: WorkerComponentServices
 Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
 Cardinality: 1..1
 Policy: static
 Policy option: reluctant
 Reference Scope: bundle
   Reference: WorkerConfiguration
 Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
 Cardinality: 1..1
 Policy: static
 Policy option: reluctant
 Reference Scope: bundle
   Component Description Properties:
   Component Configuration:
 ComponentId: 5
 State: active
 SatisfiedReference: BusService
   Target: null
   Bound to:39
   Reference Properties:
   component.id = 3
   component.name = com.basistech.ws.worker.bus.impl.BusService
   licensePathname =
/Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
   objectClass = [com.basistech.ws.worker.api.WorkerBusService]
   service.bundleid = 24
   service.id = 39
   service.pid = com.basistech.ws.bus
   service.scope = bundle
 SatisfiedReference: WorkerComponentServices
   Target: null
   Bound to:56
   Reference Properties:
   objectClass = [com.basistech.ws.worker.core.WorkerComponentServices]
   service.bundleid = 59
   service.id = 56
   service.scope = singleton
 SatisfiedReference: WorkerConfiguration
   Target: null
   Bound to:40
   Reference Properties:
   component.id = 6
   component.name =
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
   configurationFilePathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
   endpointsPathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
   native-root =
/var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
   objectClass =
[com.basistech.ws.worker.core.config.WorkerConfiguration]
   service.bundleid = 59
   service.id = 40
   service.pid = com.basistech.ws.worker
   service.scope = bundle
   subst = tsbus
 Component Configuration Properties:
 component.id = 5
 component.name = com.basistech.ws.worker.core.Worker

On Fri, Aug 12, 2016 at 6:05 AM, Ferry Huberts  wrote:


On 12/08/16 12:02, Carsten Ziegeler wrote:

Thanks Carsten, that was my expectation but I was waiting for the
“inspect cap service” output to confirm.

One thing that can be quite confusing is that the service
references, with cardinality of 1..1, are described as both
satisfied and unbound. This sounds like a contradiction until you
realise the component has not yet been instantiated. I assume that
SCR at this point does know which services it *will* bind when the
component is activated… maybe these could be shown here?


I think that would be misleading because when the bundle composition changes
before activation is needed then a different resolution can/will be
activated.


Hmm, yeah we could do that - on the other hand "unbound" means it's
satisfied, otherwise it would state the reference as "unsatisfied"
:) Maybe, it's more a wording problem?

Carsten


--
Ferry Huberts


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mai

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Benson Margulies

Thank you all. Indeed, the component was not 'immediate', and that's
why it wasn't set up.

My task of the moment it to add pax-exam tests for some individual
components; in the past, I only tested this stuff with broad
functional tests. This has led me, on this particular occasion,  end
up trying to test this not-immediate component.

How do other people create pax-exam tests for @Components that are not
immediate? By adding DS metadata to pax-exam bundles?

g! scr:info com.basistech.ws.worker.core.Worker
*** Bundle: rosapi-worker-core (59)
Component Description:
  Name: com.basistech.ws.worker.core.Worker
  Implementation Class: com.basistech.ws.worker.core.Worker
  Default State: enabled
  Activation: immediate
  Configuration Policy: ignore
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.ws.worker.core.Worker]
  Services:
com.basistech.ws.worker.api.WorkerInterface
  Service Scope: singleton
  Reference: BusService
Interface Name: com.basistech.ws.worker.api.WorkerBusService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerComponentServices
Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerConfiguration
Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Component Description Properties:
  Component Configuration:
ComponentId: 5
State: active
SatisfiedReference: BusService
  Target: null
  Bound to:39
  Reference Properties:
  component.id = 3
  component.name = com.basistech.ws.worker.bus.impl.BusService
  licensePathname =
/Users/benson/x/rosapi1.5/worker/core/../../assemblies/common-configuration/src/main/resources/etc/rosapi/rlp-license.xml
  objectClass = [com.basistech.ws.worker.api.WorkerBusService]
  service.bundleid = 24
  service.id = 39
  service.pid = com.basistech.ws.bus
  service.scope = bundle
SatisfiedReference: WorkerComponentServices
  Target: null
  Bound to:56
  Reference Properties:
  objectClass = [com.basistech.ws.worker.core.WorkerComponentServices]
  service.bundleid = 59
  service.id = 56
  service.scope = singleton
SatisfiedReference: WorkerConfiguration
  Target: null
  Bound to:40
  Reference Properties:
  component.id = 6
  component.name =
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  configurationFilePathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
  endpointsPathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
  native-root =
/var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot6966159272930866297
  objectClass =
[com.basistech.ws.worker.core.config.WorkerConfiguration]
  service.bundleid = 59
  service.id = 40
  service.pid = com.basistech.ws.worker
  service.scope = bundle
  subst = tsbus
Component Configuration Properties:
component.id = 5
component.name = com.basistech.ws.worker.core.Worker

On Fri, Aug 12, 2016 at 6:05 AM, Ferry Huberts  wrote:
>
>
> On 12/08/16 12:02, Carsten Ziegeler wrote:
>>>
>>> Thanks Carsten, that was my expectation but I was waiting for the
>>> “inspect cap service” output to confirm.
>>>
>>> One thing that can be quite confusing is that the service
>>> references, with cardinality of 1..1, are described as both
>>> satisfied and unbound. This sounds like a contradiction until you
>>> realise the component has not yet been instantiated. I assume that
>>> SCR at this point does know which services it *will* bind when the
>>> component is activated… maybe these could be shown here?
>
>
> I think that would be misleading because when the bundle composition changes
> before activation is needed then a different resolution can/will be
> activated.
>
>>>
>> Hmm, yeah we could do that - on the other hand "unbound" means it's
>> satisfied, otherwise it would state the reference as "unsatisfied"
>> :) Maybe, it's more a wording problem?
>>
>> Carsten
>>
>
> --
> Ferry Huberts
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Ferry Huberts




On 12/08/16 12:02, Carsten Ziegeler wrote:

Thanks Carsten, that was my expectation but I was waiting for the
“inspect cap service” output to confirm.

One thing that can be quite confusing is that the service
references, with cardinality of 1..1, are described as both
satisfied and unbound. This sounds like a contradiction until you
realise the component has not yet been instantiated. I assume that
SCR at this point does know which services it *will* bind when the
component is activated… maybe these could be shown here?


I think that would be misleading because when the bundle composition 
changes before activation is needed then a different resolution can/will 
be activated.





Hmm, yeah we could do that - on the other hand "unbound" means it's
satisfied, otherwise it would state the reference as "unsatisfied"
:) Maybe, it's more a wording problem?

Carsten



--
Ferry Huberts

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Carsten Ziegeler

> Thanks Carsten, that was my expectation but I was waiting for the “inspect 
> cap service” output to confirm.
> 
> One thing that can be quite confusing is that the service references, with 
> cardinality of 1..1, are described as both satisfied and unbound. This sounds 
> like a contradiction until you realise the component has not yet been 
> instantiated. I assume that SCR at this point does know which services it 
> *will* bind when the component is activated… maybe these could be shown here?
> 
Hmm, yeah we could do that - on the other hand "unbound" means it's
satisfied, otherwise it would state the reference as "unsatisfied" :)
Maybe, it's more a wording problem?

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Neil Bartlett

Thanks Carsten, that was my expectation but I was waiting for the “inspect cap 
service” output to confirm.

One thing that can be quite confusing is that the service references, with 
cardinality of 1..1, are described as both satisfied and unbound. This sounds 
like a contradiction until you realise the component has not yet been 
instantiated. I assume that SCR at this point does know which services it 
*will* bind when the component is activated… maybe these could be shown here?

Neil


> On 12 Aug 2016, at 10:50, Carsten Ziegeler  wrote:
> 
> Your service is marked as "satisfied" but as noone else is using it,
> it's not activated. That's the lazy activation of SCR.
> 
> Carsten
> 
>> I have a component, which scr:info reports that is has three unbound 
>> references.
>> 
>> scr:info on the components that provide those services seem to show
>> that they are there. And if I set breakpoints on their activate
>> methods (they are @Components), they've been called, and did not
>> throw. I've put an scr:info for one of them at the end. What would
>> cause SCR to not pass these services into the component and activate
>> it?
>> 
>> g! scr:info com.basistech.ws.worker.core.Worker
>> *** Bundle: rosapi-worker-core (59)
>> Component Description:
>>  Name: com.basistech.ws.worker.core.Worker
>>  Implementation Class: com.basistech.ws.worker.core.Worker
>>  Default State: enabled
>>  Activation: delayed
>>  Configuration Policy: ignore
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid: [com.basistech.ws.worker.core.Worker]
>>  Services:
>>com.basistech.ws.worker.api.WorkerInterface
>>  Service Scope: singleton
>>  Reference: BusService
>>Interface Name: com.basistech.ws.worker.api.WorkerBusService
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: WorkerComponentServices
>>Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Reference: WorkerConfiguration
>>Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
>>Cardinality: 1..1
>>Policy: static
>>Policy option: reluctant
>>Reference Scope: bundle
>>  Component Description Properties:
>>  Component Configuration:
>>ComponentId: 5
>>State: satisfied
>>SatisfiedReference: BusService
>>  Target: null
>>  (unbound)
>>SatisfiedReference: WorkerComponentServices
>>  Target: null
>>  (unbound)
>>SatisfiedReference: WorkerConfiguration
>>  Target: null
>>  (unbound)
>>Component Configuration Properties:
>>component.id = 5
>>component.name = com.basistech.ws.worker.core.Worker
>> 
>> 
>> 
>> g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>> *** Bundle: rosapi-worker-core (59)
>> Component Description:
>>  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>  Implementation Class:
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>  Default State: enabled
>>  Activation: immediate
>>  Configuration Policy: require
>>  Activate Method: activate
>>  Deactivate Method: deactivate
>>  Modified Method: -
>>  Configuration Pid: [com.basistech.ws.worker]
>>  Services:
>>com.basistech.ws.worker.core.config.WorkerConfiguration
>>  Service Scope: singleton
>>  Component Description Properties:
>>  Component Configuration:
>>ComponentId: 6
>>State: active
>>Component Configuration Properties:
>>component.id = 6
>>component.name =
>> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>>configurationFilePathname =
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>>endpointsPathname =
>> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>>native-root =
>> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
>>service.pid = com.basistech.ws.worker
>>subst = tsbus
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>> 
>> 
> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Carsten Ziegeler

Your service is marked as "satisfied" but as noone else is using it,
it's not activated. That's the lazy activation of SCR.

Carsten

> I have a component, which scr:info reports that is has three unbound 
> references.
> 
> scr:info on the components that provide those services seem to show
> that they are there. And if I set breakpoints on their activate
> methods (they are @Components), they've been called, and did not
> throw. I've put an scr:info for one of them at the end. What would
> cause SCR to not pass these services into the component and activate
> it?
> 
> g! scr:info com.basistech.ws.worker.core.Worker
> *** Bundle: rosapi-worker-core (59)
> Component Description:
>   Name: com.basistech.ws.worker.core.Worker
>   Implementation Class: com.basistech.ws.worker.core.Worker
>   Default State: enabled
>   Activation: delayed
>   Configuration Policy: ignore
>   Activate Method: activate
>   Deactivate Method: deactivate
>   Modified Method: -
>   Configuration Pid: [com.basistech.ws.worker.core.Worker]
>   Services:
> com.basistech.ws.worker.api.WorkerInterface
>   Service Scope: singleton
>   Reference: BusService
> Interface Name: com.basistech.ws.worker.api.WorkerBusService
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: WorkerComponentServices
> Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Reference: WorkerConfiguration
> Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
> Cardinality: 1..1
> Policy: static
> Policy option: reluctant
> Reference Scope: bundle
>   Component Description Properties:
>   Component Configuration:
> ComponentId: 5
> State: satisfied
> SatisfiedReference: BusService
>   Target: null
>   (unbound)
> SatisfiedReference: WorkerComponentServices
>   Target: null
>   (unbound)
> SatisfiedReference: WorkerConfiguration
>   Target: null
>   (unbound)
> Component Configuration Properties:
> component.id = 5
> component.name = com.basistech.ws.worker.core.Worker
> 
> 
> 
> g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
> *** Bundle: rosapi-worker-core (59)
> Component Description:
>   Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>   Implementation Class:
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>   Default State: enabled
>   Activation: immediate
>   Configuration Policy: require
>   Activate Method: activate
>   Deactivate Method: deactivate
>   Modified Method: -
>   Configuration Pid: [com.basistech.ws.worker]
>   Services:
> com.basistech.ws.worker.core.config.WorkerConfiguration
>   Service Scope: singleton
>   Component Description Properties:
>   Component Configuration:
> ComponentId: 6
> State: active
> Component Configuration Properties:
> component.id = 6
> component.name =
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
> configurationFilePathname =
> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
> endpointsPathname =
> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
> native-root =
> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
> service.pid = com.basistech.ws.worker
> subst = tsbus
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 
> 


 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Neil Bartlett

Please show:

1. The scr:info for the component that has unbound service references
2. The “inspect service” output that proves a service is available (showing 
scr:info for some other component does NOT prove this).

Neil



> On 12 Aug 2016, at 03:12, Benson Margulies  wrote:
> 
> I have a component, which scr:info reports that is has three unbound 
> references.
> 
> scr:info on the components that provide those services seem to show
> that they are there. And if I set breakpoints on their activate
> methods (they are @Components), they've been called, and did not
> throw. I've put an scr:info for one of them at the end. What would
> cause SCR to not pass these services into the component and activate
> it?
> 
> g! scr:info com.basistech.ws.worker.core.Worker
> *** Bundle: rosapi-worker-core (59)
> Component Description:
>  Name: com.basistech.ws.worker.core.Worker
>  Implementation Class: com.basistech.ws.worker.core.Worker
>  Default State: enabled
>  Activation: delayed
>  Configuration Policy: ignore
>  Activate Method: activate
>  Deactivate Method: deactivate
>  Modified Method: -
>  Configuration Pid: [com.basistech.ws.worker.core.Worker]
>  Services:
>com.basistech.ws.worker.api.WorkerInterface
>  Service Scope: singleton
>  Reference: BusService
>Interface Name: com.basistech.ws.worker.api.WorkerBusService
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Reference: WorkerComponentServices
>Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Reference: WorkerConfiguration
>Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
>Cardinality: 1..1
>Policy: static
>Policy option: reluctant
>Reference Scope: bundle
>  Component Description Properties:
>  Component Configuration:
>ComponentId: 5
>State: satisfied
>SatisfiedReference: BusService
>  Target: null
>  (unbound)
>SatisfiedReference: WorkerComponentServices
>  Target: null
>  (unbound)
>SatisfiedReference: WorkerConfiguration
>  Target: null
>  (unbound)
>Component Configuration Properties:
>component.id = 5
>component.name = com.basistech.ws.worker.core.Worker
> 
> 
> 
> g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
> *** Bundle: rosapi-worker-core (59)
> Component Description:
>  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>  Implementation Class:
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>  Default State: enabled
>  Activation: immediate
>  Configuration Policy: require
>  Activate Method: activate
>  Deactivate Method: deactivate
>  Modified Method: -
>  Configuration Pid: [com.basistech.ws.worker]
>  Services:
>com.basistech.ws.worker.core.config.WorkerConfiguration
>  Service Scope: singleton
>  Component Description Properties:
>  Component Configuration:
>ComponentId: 6
>State: active
>Component Configuration Properties:
>component.id = 6
>component.name =
> com.basistech.ws.worker.core.config.WorkerConfigurationImpl
>configurationFilePathname =
> /Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
>endpointsPathname =
> /Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
>native-root =
> /var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
>service.pid = com.basistech.ws.worker
>subst = tsbus
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Solved felix SCR Logging, but replaced that with a problem with optional dependency resolution in the framework

2016-08-12 Thread Erwin Hogeweg

Benson,

> 
> But I just figured out how to get the equinox log where I can see it, maybe.
Talk to us ;-). I have been following this thread with great interest because I 
have the exact same problem. A bunch of services bind to the Equinox log 
service but the output is nowhere to be found. 

Would you mind sharing what you found and make this a better place? ;-)

Cheers,

Erwin.
-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

scr claims to be unsatisfied for service that seems to be there

2016-08-12 Thread Benson Margulies

I have a component, which scr:info reports that is has three unbound references.

scr:info on the components that provide those services seem to show
that they are there. And if I set breakpoints on their activate
methods (they are @Components), they've been called, and did not
throw. I've put an scr:info for one of them at the end. What would
cause SCR to not pass these services into the component and activate
it?

g! scr:info com.basistech.ws.worker.core.Worker
*** Bundle: rosapi-worker-core (59)
Component Description:
  Name: com.basistech.ws.worker.core.Worker
  Implementation Class: com.basistech.ws.worker.core.Worker
  Default State: enabled
  Activation: delayed
  Configuration Policy: ignore
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.ws.worker.core.Worker]
  Services:
com.basistech.ws.worker.api.WorkerInterface
  Service Scope: singleton
  Reference: BusService
Interface Name: com.basistech.ws.worker.api.WorkerBusService
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerComponentServices
Interface Name: com.basistech.ws.worker.core.WorkerComponentServices
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Reference: WorkerConfiguration
Interface Name: com.basistech.ws.worker.core.config.WorkerConfiguration
Cardinality: 1..1
Policy: static
Policy option: reluctant
Reference Scope: bundle
  Component Description Properties:
  Component Configuration:
ComponentId: 5
State: satisfied
SatisfiedReference: BusService
  Target: null
  (unbound)
SatisfiedReference: WorkerComponentServices
  Target: null
  (unbound)
SatisfiedReference: WorkerConfiguration
  Target: null
  (unbound)
Component Configuration Properties:
component.id = 5
component.name = com.basistech.ws.worker.core.Worker



g! scr:info com.basistech.ws.worker.core.config.WorkerConfigurationImpl
*** Bundle: rosapi-worker-core (59)
Component Description:
  Name: com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Implementation Class:
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
  Default State: enabled
  Activation: immediate
  Configuration Policy: require
  Activate Method: activate
  Deactivate Method: deactivate
  Modified Method: -
  Configuration Pid: [com.basistech.ws.worker]
  Services:
com.basistech.ws.worker.core.config.WorkerConfiguration
  Service Scope: singleton
  Component Description Properties:
  Component Configuration:
ComponentId: 6
State: active
Component Configuration Properties:
component.id = 6
component.name =
com.basistech.ws.worker.core.config.WorkerConfigurationImpl
configurationFilePathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/path-subst-worker-config.yaml
endpointsPathname =
/Users/benson/x/rosapi1.5/worker/core/src/test/config/all-endpoints-no-dte.yaml
native-root =
/var/folders/80/5l86669j3278_x4hlpntlz38gp/T/nativeroot7939628695379969633
service.pid = com.basistech.ws.worker
subst = tsbus

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: how to enable felix verify the contents of a signed bundle

how to enable felix verify the contents of a signed bundle

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: scr claims to be unsatisfied for service that seems to be there

Re: Solved felix SCR Logging, but replaced that with a problem with optional dependency resolution in the framework

scr claims to be unsatisfied for service that seems to be there

13 matches

Site Navigation

Mail list logo

Footer information