Thread freeze during pax test method execution


Hi, I've written to stack overflow about my issiue: (I've attached it as a PDF on this report - hope that is ok?)

Short summary (please tell me if I should place all my stackoverflow explanation here as well ).

I've written a few services that depends on config admin (ie require) and I use config admin factory to create several instance of the services when I do conf.update(props) in my test. I then create a service tracker that waits a few seconds just to se the services being instantiated. However the wait times out and it exits the test method. During the container disposal I can se in the log that my services are created then. I've also tried to use ConfigurationAdminOptions.factoryConfiguration in the @org.ops4j.pax.exam.Configuration
public Option[] config() { .. }
phase and that worked alright also. It seems that everything (other threads) than the actual test thread during test method execution.

The only exceptional is when I've moved from Karaf 4.0.0.M2 to 4.0.0 GA is that I get an exception in the beginning - but karaf seems to deploy features anyhow (see below log dump)

I've attached a log file both when doing config admin factory config as an option (where it do instantiate the service before running the test method and a logg (config-admin-within-test-method.txt) where I do it within the test method and the service will instantiate after the test method has finished.

The log for CouchbaseConnectionProviderImpl is when my service is activated. This first log shows no "svc is null" (nor do the service tracker time-out) and the other is waiting and "svc is null" is shown (and the service tracker has timed out) and after that one can se in the log while the container is disposing it will instantiate and activate the service.



Linux, Ubuntu 14.04LTS, Eclipse 4.4.2, Parallells virtualized, Karaf 4.0.0, Maven 3.0.5, java 1.8.0_45


Mario Toffia
July 9, 2015, 10:18 AM

Uploaded a test-TRACE-enabled.txt logfile. On line 511 the service is started. Ive separated the log in to two parts, line 445 is where the separator is and where it uses the service tracker wait. The last log statements before the wait is:

2015-07-09 12:06:07,216 | INFO | Thread-20 | CouchbaseConnectionProviderTests | 81 - PAXEXAM-PROBE-e7e4a746-e7fc-4829-8acc-e5fa994e3091 - 0.0.0 | Updated properties, will async create new instance
2015-07-09 12:06:07,216 | DEBUG | 92-1d9826ed92ed) | configadmin | 3 - org.apache.felix.configadmin - 1.8.4 | getProperties()
2015-07-09 12:06:07,224 | DEBUG | 92-1d9826ed92ed) | configadmin | 3 - org.apache.felix.configadmin - 1.8.4 | getProperties()
2015-07-09 12:06:07,224 | DEBUG | 92-1d9826ed92ed) | configadmin | 3 - org.apache.felix.configadmin - 1.8.4 | getChangeCount()

and then it freezes until giving up wait and the log continues.


Christoph Läubrich
July 9, 2015, 11:24 AM

Okay I think I know what might be the problem now:
You are using the createFactoryConfiguration(java.lang.String factoryPid), this means you will create a configuration that is exclusivly bound to your bundle! Thus no other bundle is allowed to access the configuration!
Use the createFactoryConfiguration(java.lang.String factoryPid, java.lang.String location) instead with a null argument for the location! This way you create an anonymous configuration that will be bound to the first bundle that fetches this config. Alternativly you can get the location of the target bundle and explicitly pass this as an parameter, but this is often not needed.

If this still do not work, we must take a closer look at your configuration, connect to the karaf shell (while stopped at a breakpoint) and get a list of all bundles (bundle:list) and a list of all components (scr:list).
Also you should collect detailed information about the probe bundle and the bundle that should provide the service (packages:imports).

Mario Toffia
July 9, 2015, 11:38 AM

Yes!! that did work - sorry for being clumsy and reported this as a bug - this is my fault - not being good enough in how config admin worked sorry

So if I understand you correctly
1) My config was bound to my pax generated bundle?
2) Is the pax generated bundle in some state that prevented config admin to access that config (since config admin always can manage configuration - right?)

Due to the fact that my service was eventually instantiated (when exit the test method)

Thank you wery much for your support - you have saved my day!


Christoph Läubrich
July 9, 2015, 11:40 AM

Closing as not-a-bug

Christoph Läubrich
July 9, 2015, 11:49 AM

1) is correct, it is then "bound to the calling bundle" in this case it is your test-probe bundle
2) the config-admin can access it without a problem, but your "DS-Bundle" (while not directly accessing the configuration but through the SCR bundle) can't and thus won't see there is any configuration to pick up.

This is a security feature, so other bundles can't access configuration that is not targeted at them. In your case the configuration contains passwords for example so you normally won't allow to access this by every bundle in the system e.g. malicous ones...

Why the configuration is "free'ed" in the end and is accessible to other bundles might be a bug in the CM implementation but to say more about that I think further investigations/tests are needed.


Christoph Läubrich


Mario Toffia



Affects versions