[
https://issues.apache.org/jira/browse/TAMAYA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15771109#comment-15771109
]
ASF subversion and git services commented on TAMAYA-210:
--------------------------------------------------------
Commit 7b9971d81f98c486fb356bff28eacb23af122706 in incubator-tamaya-sandbox's
branch refs/heads/master from [~anatole]
[
https://git-wip-us.apache.org/repos/asf?p=incubator-tamaya-sandbox.git;h=7b9971d
]
TAMAYA-210: Added additional resource location logic. Tested and implemented
especially with OSGI.
TAMAYA-148: Further tests with OSGI/Karaf.
> Improve resource loading in OSGI
> --------------------------------
>
> Key: TAMAYA-210
> URL: https://issues.apache.org/jira/browse/TAMAYA-210
> Project: Tamaya
> Issue Type: Improvement
> Components: API, Core
> Affects Versions: 0.2-incubating
> Reporter: Anatole Tresch
> Assignee: Anatole Tresch
> Fix For: 0.3-incubating
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
