Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
0.2-incubating
-
None
Description
The current OSGI implementation of the core framework does leverage the OSGI service functionality, for registering services registered using the Java ServiceLoader syntax. This works good, but has some limitations:
- Loading of the ConfigurationProviderSpi regularly fails because the service has not been registered, when the class is loaded. To resolve this issue, the OSGIServiceContext should return the default implementation, if none has been found in the bundle context (in almost all cases this is the final target state anyway).
- Loading of classpath resources such as config files through classloader obviously fails since OSGI classloaders do behave significantly different. Therefore the ServiceContext API should be extended with two methods URL getResource(String, ClassLoader), Enumeration<URL> getResources(String, ClassLoader) to implement the logic that best fits for the current target runtime, especially OSGI. These methods also map perfectly to the OSGI counterparts, as well as the default methods available on the classloaders anyway.
- Finally there is the question how Tamaya gets aware of bundles that contain configuration resources Tamaya services should see. This problem can be solved by adding a marker file META-INF/TamayaResource with arbitrary content to the bundles that provide sich resources. Within the service registration process Tamaya as of now already registers itself as a BundleListener so it is easy to track all bundles that are relevant.
