Okay, then try the following:
a) use the remote container to archive maximum classloader-isolation, in
larger applications you can easily pull in multiple dependencies for the
same interface what can mess up with Pax-Exam
b) activate remote debugging for your container, set a breakpoint in a
test method, add large timeouts to service references and activate and
connect to the gogo shell and/or webconsole to have access to OSGi
debugging capabilities
c) check that all relevant bundles (examp-test-probe, exam-cm-provider
bundle, your ds component, felix-scr) are bound to the same
org.osgi.service.cm package-import.
Even though its hard to guess without any detailed information (maybe
you can share at least the output of |scr info| or something similar?)
for me it sounds like there is more than one version of the cm-package
avaiable in your current setup.
Am 31.10.2016 19:16, schrieb Benson Margulies:
On Mon, Oct 31, 2016 at 2:12 PM, 'Christoph Läubrich' via OPS4J
<[email protected]> wrote:
You should then activate the debug options of Felix SCR to see whats going
on.
Not only have I spend hours staring at the logging output of SCR, I've
_debugged SCR_. Set breakpoints in it. Seen that, in particular, it
seems to be never notified of the arrival of the ConfigurationAdmin
service.
Can you share the "working" vs the "not working" code?
Unfortunately, no. It's part of a large, non-open-source, system.
Essentially, I'll have to debug it in place to create a test case that
I can share.
What
Pax-Container do you use? Remote? Embedded?
The default embedded Felix container with Felix 5.4.0.
Have you tried to use
immediate="true" for your component to make sure it is not delayed?
Yes.
--
--
------------------
OPS4J - http://www.ops4j.org - [email protected]
---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
