I could, but it's really very simple.
The ComponentDescriptionDTO contains the static information that
corresponds to the @Component.
The surprise is that
configs = scrRuntime.getComponentConfigurationDTOs(descDTO);
returns no configuration DTO's at all. Are there really further
details that would shed light? I also have all the logging from Felix
SCR, but that seems better suited to the felix list.
On Tue, Oct 18, 2016 at 9:20 AM, Raymond Auge <raymond.a...@liferay.com> wrote:
> Perhaps it might help to show the DTO you've dumped here so more eyes can
> look at it.
>
> Sincerely,
> - Ray
>
> On Tue, Oct 18, 2016 at 8:46 AM, Benson Margulies <bimargul...@gmail.com>
> wrote:
>>
>> On Tue, Oct 18, 2016 at 8:40 AM, Timothy Ward <tim.w...@paremus.com>
>> wrote:
>> > How are you creating the configuration?
>> >
>> > Configuration Admin uses the concept of a bundle location to restrict
>> > the visibility of a pid to a particular bundle. This almost always trips
>> > people up when they create the configuration themselves (i.e. in code) as
>> > the “default” methods bind the configuration to the bundle creating it
>> > (rarely what you actually want).
>>
>> I carefully use a 'null' location:
>>
>> configurationAdmin.getConfiguration(pid, null);
>>
>> which I thought was the right recipe.
>>
>> Here's some debug from felix CM:
>>
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]getConfiguration(pid=com.basistech.ws.bus,
>> location=null)
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]No SecurityManager
>> installed; grant CONFIGURE permission on configuration bound to * to
>> bundle
>> /Users/benson/x/rosapi-on-premise/embedded/test/../pre-package/target/bundles/base/rosapi-headless-config-reader-1.4.101-SNAPSHOT.jar
>> 08:37:00.164 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]createConfiguration(com.basistech.ws.bus,
>> null, null)
>> 08:37:00.165 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]update(properties={licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml})
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Updating config
>> com.basistech.ws.bus with
>>
>> {licensePathname=/Users/benson/x/rosapi-on-premise/embedded/test/target/test-config/rosapi/rlp-license.xml}
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]No
>> SynchronousConfigurationListeners to send CM_UPDATED event to.
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Fire
>> ConfigurationEvent: pid=com.basistech.ws.bus
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>> [[org.osgi.service.cm.ConfigurationAdmin]]Scheduling task Update:
>> pid=com.basistech.ws.bus
>> 08:37:00.166 [CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=com.basistech.ws.headless.config)] DEBUG
>> org.apache.felix.configadmin.1.8.10 -
>>
>> [[org.osgi.service.cm.ConfigurationAdmin]]UpdateConfiguration(com.basistech.ws.bus)
>> scheduled
>>
>>
>>
>> >
>> > Also, if your component is not immediate *and* it provides a service
>> > then it will not activate until somebody “gets” the service.
>>
>> Yes, but I have 10 other components stuck waiting for it, so that
>> problem should be solved.
>>
>> While I thank you for advice on diagnosing the problem, I also want to
>> remind you that my original question is how the state is reflected in
>> the DTOs. Solving the actual problem is probably just a matter of log
>> comparison with the working environment.
>>
>>
>> >
>> > Regards,
>> >
>> > Tim
>> >
>> >
>> >> On 18 Oct 2016, at 12:47, Benson Margulies <bimargul...@gmail.com>
>> >> wrote:
>> >>
>> >> Here's my puzzle.
>> >>
>> >> I have a set of services that all have unsatisfied references to the
>> >> same thing - a vanilla @Reference to the interface WorkerBusService.
>> >>
>> >> In each case, there is a configuration DTO with an unsatisfied
>> >> reference with name BusConfigured and target null.
>> >>
>> >> WorkerBusService is implemented by an @Component named BusService.
>> >>
>> >> it has a required configuration pid and is _not_ immediate. The
>> >> configuration should be there, I see a log message corresponding to my
>> >> code that updates it into place.
>> >>
>> >> When things time out, BusService has no configuration dtos at all,
>> >> just the description DTO. So, how do I tell why it hasn't started?
>> >> Note that this is an environment where I can't use the shell, so I've
>> >> basically written code that dumps useful output from the introspection
>> >> into a String.
>> >>
>> >> Note that all this works in a slightly different environment, and I'm
>> >> trying to hone these diagnostic tools rather than brute-force a
>> >> comparison to explain the discrepancy.
>> >> _______________________________________________
>> >> OSGi Developer Mail List
>> >> osgi-dev@mail.osgi.org
>> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> >
>> > _______________________________________________
>> > OSGi Developer Mail List
>> > osgi-dev@mail.osgi.org
>> > https://mail.osgi.org/mailman/listinfo/osgi-dev
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
> --
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance)
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
