On Thu, Jul 12, 2018 at 2:01 AM, Cristiano <cvgav...@gmail.com> wrote:
> Hi Neil,
>
> yes, it was the output from felix scr:list command.
>
> Take a look at the bundles loaded in PDE below.
>
> id State Bundle
>> 0 ACTIVE org.eclipse.osgi_3.13.0.v20180409-1500
>> Fragments=18
>> 1 STARTING br.com.c8tech.osgi.lib.cm_0.1.1.SNAPSHOT
>> 2 STARTING br.com.c8tech.osgi.lib_0.1.1.SNAPSHOT
>> 3 ACTIVE ch.qos.logback.classic_1.2.3
>> 4 ACTIVE ch.qos.logback.core_1.2.3
>> 5 ACTIVE org.apache.felix.gogo.command_1.0.2
>> 6 ACTIVE org.apache.felix.gogo.runtime_1.1.0
>> 7 ACTIVE org.apache.felix.gogo.shell_1.1.0
>> 8 ACTIVE org.apache.felix.logback_1.0.0
>> *9 ACTIVE org.apache.felix.scr_2.1.0*
>> 10 ACTIVE org.eclipse.equinox.cm_1.3.0.v20180418-1839
>> 11 ACTIVE org.eclipse.equinox.common_3.10.0.v20180412-1130
>> 12 ACTIVE org.eclipse.equinox.console_1.3.0.v20180119-0630
>> 13 RESOLVED org.eclipse.equinox.coordinator_1.3.500.v20171221-2204
>> 14 ACTIVE org.eclipse.equinox.ds_1.5.100.v20171221-2204
>> 15 ACTIVE org.eclipse.equinox.event_1.4.200.v20180426-0845
>> 16 RESOLVED org.eclipse.equinox.metatype_1.4.400.v20180501-1616
>> 17 ACTIVE org.eclipse.equinox.preferences_3.7.100.v20180510-1129
>> 18 RESOLVED org.eclipse.equinox.region_1.4.100.v20171221-2204
>> Master=0
>> 19 ACTIVE org.eclipse.equinox.util_1.1.0.v20180419-0833
>> 20 RESOLVED org.eclipse.osgi.services_3.7.0.v20180223-1712
>> 21 RESOLVED org.eclipse.osgi.util_3.5.0.v20180219-1511
>> 22 RESOLVED slf4j.api_1.7.25
>>
>
I notice that you are using both org.eclipse.equinox.ds AND
org.apache.felix.scr. You really shouldn't use multiple SCR implementations
in the same OSGi Framework, they are likely to conflict and/or create
duplicates of every component.
>
> and if you repair a bit in my latest email, you will see that I've passed
> the component name to the scr:info command.
>
This is probably the problem. If you pass in the ID of a component
configuration (which will be a number) then you will see the full
inspection information for that configuration. If you only pass a component
name then you will see higher level information.
>
>
> Well, after a loooong day playing with this issue I finally found the
> reason of such weird problem: *can't use **org.apache.felix.scr_2.1.0 with
> **equinox photon *!!!
>
I do not think this is true.
>
> even though *org.eclipse.equinox.ds* is allowing it on its manifest:
>
Again, you don't need two SCR implementations! You should just remove
org.eclipse.equinox.ds.
>
> Require-Bundle: org.apache.felix.scr;bundle-ve
>> rsion="[2.0.0,3.0.0)";visibility:=reexport
>>
>
> and also org.apache.felix.scr is being activated without any error:
>
> 20:55:20||INFO|ServiceEvent REGISTERED {org.apache.felix.scr.ScrService}={
>> service.id=48, service.bundleid=14, service.scope=singleton}|E.S.o
>> .eclipse.equinox.ds||E.S.o.e.e.ds@?[Start Level: Equinox Container:
>> efcce77e-ec67-408f-a0a2-1a83d6547c3c]
>>
>
>
> I was not able to discover the real reason for that incompatibility. maybe
> is something related to equinox.ds reexporting felix.scr packages or
> because it is tied to DS 1.3.
>
>
> But the fact is that after I have replaced the org.apache.felix.scr by
> version 2.0.14 I was able to debug and identify my issue. :-)
>
> I've simulated one problem (removed EventAdmin bundle) just to show how
> different the output of the command scr:info is now:
>
> g! scr:info c8tech.osgi.lib.cm.internal.ComponentProviderConfigurationEx
>> tendedService
>> *** Bundle: br.com.c8tech.osgi.lib.cm (1)
>> Component Description:
>> Name: c8tech.osgi.lib.cm.internal.ComponentProviderConfigurationEx
>> tendedService
>> Implementation Class: c8tech.osgi.lib.cm.internal.Co
>> mponentProviderConfigurationExtendedService
>> Default State: enabled
>> Activation: immediate
>> Configuration Policy: optional
>> Activate Method: activate
>> Deactivate Method: deactivate
>> Modified Method: -
>> Configuration Pid: [c8tech.osgi.lib.cm.internal.C
>> omponentProviderConfigurationExtendedService]
>> Services:
>> c8tech.osgi.lib.api.cm.ConfigurationAdminExtendedService
>> Service Scope: singleton
>> Reference: ConfigurationAdmin
>> Interface Name: org.osgi.service.cm.ConfigurationAdmin
>> Cardinality: 1..1
>> Policy: static
>> Policy option: reluctant
>> Reference Scope: bundle
>> Reference: EventAdminService
>> Interface Name: org.osgi.service.event.EventAdmin
>> Cardinality: 1..1
>> Policy: static
>> Policy option: reluctant
>> Reference Scope: bundle
>> Reference: PreferencesService
>> Interface Name: org.osgi.service.prefs.PreferencesService
>> Cardinality: 1..1
>> Policy: static
>> Policy option: reluctant
>> Reference Scope: bundle
>> Component Description Properties:
>> Component Configuration:
>> ComponentId: 0
>> State: unsatisfied reference
>> SatisfiedReference: ConfigurationAdmin
>> Target: null
>> (unbound)
>> SatisfiedReference: PreferencesService
>> Target: null
>> (unbound)
>> UnsatisfiedReference: EventAdminService
>> Target: null
>> (no target services)
>> Component Configuration Properties:
>> component.id = 0
>> component.name = c8tech.osgi.lib.cm.internal.Co
>> mponentProviderConfigurationExtendedService
>>
>
> thanks to all,
>
> Cristiano
>
>
>
> On 11/07/2018 15:21, Neil Bartlett wrote:
>
>> Indeed this cannot be the scr:info command from Felix SCR, because the
>> Felix command requires an argument (the component ID) and would have
>> failed
>> when called without one.
>>
>> Perhaps a bundle listing would help us identify what you are working with.
>>
>> Neil
>>
>>
>>
>
