[
https://issues.apache.org/jira/browse/TAMAYA-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765306#comment-16765306
]
ASF subversion and git services commented on TAMAYA-383:
--------------------------------------------------------
Commit ceb848ab2b14b1422688218afa668b4b4742c857 in incubator-tamaya's branch
refs/heads/master from William Lieurance
[ https://gitbox.apache.org/repos/asf?p=incubator-tamaya.git;h=ceb848a ]
TAMAYA-383 Let OSGi skip thread classloader key
We use the thread's classloader as a key into a hashmap to find the
serviceloader for a given configuration. In OSGi, we have separate
classloaders for the CoreConfigurationBuilder,
DefaultConfigurationBuilder, and ServiceContextManager. That confusion
prevents the simple case from finding a match in the hashmap that can
load a particular ServiceContext. Since
CoreConfiguation/DefaultConfiguration already uses the static class's
classloader during <init>, this PR allows the OSGIActivator to point
that classloader at the relevant OSGIServiceContext.
> Problem with ServiceContext in ServiceContextManager
> ----------------------------------------------------
>
> Key: TAMAYA-383
> URL: https://issues.apache.org/jira/browse/TAMAYA-383
> Project: Tamaya
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.4-incubating
> Reporter: Christian Niehues
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> After a longer period I updated my tamaya sources from master and deployed
> them into my existing karaf project. After that the core tamaya-core bundle
> fails to start the OSGIActivator because of ConfigException "No
> ServiceContext found".
> The exception comes from ServiceContextManager::loadDefaultServiceProvider
> which always try to get a new(best) Service Provider instead of using the one
> got from ServiceContextManager::set method like in older implementations. The
> problem is that ServiceLoader.load(ServiceContext.class, classLoader) doesn't
> find anything and I ask myself if it shouldn't be a OSGIServiceLoader do find
> the service declaration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
