The Framework must not recursively call ServiceFactory::GetService and ServiceFactory::UngetService on the same thread for the same bundle

[jeffdiclemente]

According to the OSGi spec for a ServiceFactory, the getService(Bundle bundle,ServiceRegistration<S> registration) method states:

If this method is recursively called for the specified bundle, a
framework event of type FrameworkEvent.ERROR is fired containing a service exception of type
ServiceException.FACTORY_RECURSION and null is returned to the bundle.

The Framework currently doesn't enforce this. This issue is to track the implementation of this constraint.

[jeffdiclemente]

Sascha described in #202 how this behavior could happen:

When the framework calls GetService, it effectively calls into external code and the service factory implementation could (in theory) call GetService or UngetService on the same factory instance again (either explicitly or implicitly via calling back into the framwork API). This needs to be detected and handled.

Test code needs to be written to trigger this behavior and verify the implementation fixes the issue.

[saschazelzer]

I am reading paragraph 10.1.25.1 of the OSGi Core 6.0 specs about service factories. The specified error handling is not in line with our code in ServiceReferenceBasePrivate::GetServiceFromFactory and I am thinking about using the correct FrameworkEvent::Type enum (error instead of warning) and using our existing ServiceException class in the created framework event. Do you disagree?

[jeffdiclemente]

That all sounds good to me. I noticed that code coverage for the ServiceException is low and this is a great opportunity to increase it.

It does beg the question on whether we should implement the BundleException class and use it consistently.

Also, I think that the work to convert over to consistently using ServiceException should be a separate issue independent of this one.

[saschazelzer]

Good points. I think we should implement BundleException and use it consistently, ideally in 3.x in a backwards compatible manner. I am going to create new issues.

[jeffdiclemente]

I agree on using BundleExceptions consistently and in a backwards compatible way for 3.x.

Thanks!

[saschazelzer]

The implementation in #222 makes use of a thread-local variable. Segmentation faults of tests from builds based on MingGW revealed a problem with the TLS implementation in libwinpthreads, which is also noted here:

https://github.com/Alexpux/MINGW-packages/issues/2519
https://sourceforge.net/p/mingw-w64/bugs/527/

Therefore, the checks for recursive service factory calls are going to be disabled for MinGW platforms until this is resolved.