Unexpected wait-for-dependencies:=false behavior

[audley]

I have a bundle that creates a bean with two service dependencies. One service is stable and expected to be available immediately, the other is a dynamic service that comes and goes over time. Both services are declared as mandatory.

I set the wait-for-dependencies directive to false in the bundle manifest, so I expect the context to start immediately, even though the dynamic service won't be available for a minute or so after the OSGi container is started.

I'm using eclipse equinox 3.5. When I start my system, the context for this bundle is created immediately and I see my bean instantiated. The log file indicates that the spring extender finds the first service as expected but doesn't find the dynamic service. However, neither service proxy is set on my bean. I have the bean setup as a listener on the dynamic service, and when the service is finally bound, the service proxies for both services still haven't been set on the bean. Both service proxies are set after the final service is bound.

The documentation for wait-for-dependencies in section 6.1 of the documentation says that a service proxy for the unsatisfied service dependency will be assigned to the bean, even if it is declared mandatory. Why isn't this happening? Also, why isn't the service proxy for the other service which is found being assigned to the bean?

[audley]

The documentation for Spring DM, Chapter 6.1 states that when wait-for-dependencies is set to false...

"Context creation will begin immediately even if dependencies are not satisfied. This essentially means that mandatory service references are treated as though they were optional - clients will be injected with a service object that may not be backed by an actual service in the registry initially."

The first sentence is correct; context creation will begin immediately and this could mean that some beans are created right away. However, mandatory service references are NOT treated as though they were optional. The ServiceDynamicInterceptor used to create the proxy for the mandatory services will still have the 'requiredAtStartup' property set to true. Therefore, the getObject() call on the OsgiServiceProxyFactoryBean will block context creation from continuing until the referenced service is available.

I believe the code at OsgiServiceProxyFactoryBean:176 should read something like

    lookupAdvice.setRequiredAtStartup(
            getCardinality().isMandatory() && wait-for-deps);

Although there isn't a value or method available at that point in the code for accessing the value of the wait-for-dependencies directive and it would have to be parsed from the bundle headers (with the appropriate default applied).

[Costin Leau]

Audley, I've raised http://jira.springframework.org/browse/OSGI-791 to track this down. I've scheduled for 1.2.1 and I'm planning to look at it in the near future.

[Costin Leau]

Audley, I've looked closer at the issue you reported and you're right - according to the documentation, the header should prevent the mandatory checks from occurring. Which ironically happens but not the way you expect it - namely, until 1.2.x, the mandatory proxies check the service availability at startup, independent on the startup check for all services.
So while setting the header stops the listener from searching all the mandatory dependencies and checking their availability, each proxy in return, once started, will look for its backing service causing a similar (yet slightly different) behaviour.
In Spring DM 2.x we've changed this behaviour so the mandatory proxies do not execute this extra check as it proved counter-intuitive and repetitive. Fixing this in 1.2.x, would cause too much disruption and with 2.x already in the works and moving nicely towards GA, I opted to close OSGI-791 and raise OSGI-794 to double check the behaviour in 2.x (should work just fine).
It would be great if you could try 2.x and see whether your problem is fixed or not.

Thanks,