I'm sorry to have been sending various noisy email messages over the last few days about a mystery of mine. The mystery still exists: changing various details got one configuration to work, but I am still confronted with it. I want to emphasize that, to my embarrassment, I have yet to find a meaningful difference between the working and non-working instances. Here I attempt a relatively concise explanation of the device, in the hopes that I've done something that is manifestly wrong to a reader.
At the outermost later, I have a Java class that launches the framework with some packages added to the system bundle, and then uses a service tracker to wait for a service for an interface in one of those package. That service is the result of an 'immediate=true' @Component, which has a rich tree of dependencies. The component never activates. The service tracker returns a timeout indication. When the timeout happens, I call into the framework to run code that uses the scr runtime to dump out the DTOs for all of the components that are not ACTIVE. If I try to analyze this information, what I observe is a chain of unsatisfied dependencies that reach a component named BusService. BusService has, as of now, an OPTIONAL configuration PID, and a single mandatory reference. The service it @Reference-es is there. It is not an @Component. It's an old-fashioned service, and I can set a breakpoint and watch it get registered. Yet the set method for it is never called in BusService. Yet, when I dump the DTOs, I get the following. It's SATISFIED, in spite of having a reference for which the setter has never been called. It's not ACTIVE, even though other components are unsatisfied on it. I suppose my debugger may be playing tricks on me. name: com.basistech.ws.worker.bus.impl.BusService bundle: rosapi-worker-bus 1.4.101.201610191610 state: 4 SATISFIED id: 8 prop component.name: com.basistech.ws.worker.bus.impl.BusService prop component.id: 8 Satisfied: Bus target null Finally, I want to explain that the outer framework calls ServiceTracker.waitForService in the same thread that sets up the framework. I've observed that the framework creates plenty of its own threads. Anyway, this is my last noise on this subject unless (a) someone has a clarifying question, or (b) I figure it out and learn something of general utility. I will be beer-buying grateful if someone can give me a shove in a productive direction here. If I had to lash out at random, I might try pushing the ServiceTracker usage to be _inside_ the framework via a very simple @Component with no dependencies that, when asked, tracks and returns (or fails to return) the production service. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
