本文介绍了在OSGi容器中找不到OpenSAML3资源'default-config.xml'的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试使用opensaml servicemix捆绑包(org.apache.servicemix.bundles:org.apache.servicemix.bundles.opensaml:jar:3.2.0_1)在Apache Karaf(4.0.5)上运行的OSGi捆绑包中升级到OpenSAML 3.

I'm trying to upgrade to OpenSAML 3 in an OSGi bundle running on Apache Karaf (4.0.5) using opensaml servicemix bundle (org.apache.servicemix.bundles:org.apache.servicemix.bundles.opensaml:jar:3.2.0_1).

解析SAML的测试正在运行,因此我认为我的工作是正确的.但是,如果我在Karaf上安装捆绑软件,则尝试加载default-config.xml时会出现找不到资源" 错误.

A test that parses the SAML is working so I think I'm on the right track. However, if I install the bundle on Karaf I get a "resource not found" error when it's trying to load default-config.xml.

2016-06-21 16:29:10,477 | INFO  | ool-120-thread-1 | InitializationService            | 388 - org.apache.servicemix.bundles.opensaml - 3.2.0.1 | Initializing OpenSAML using the Java Services API
2016-06-21 16:29:10,478 | DEBUG | ool-120-thread-1 | InitializationService            | 388 - org.apache.servicemix.bundles.opensaml - 3.2.0.1 | Initializing module initializer implementation: org.opensaml.core.xml.config.XMLObjectProviderInitializer
2016-06-21 16:29:10,487 | DEBUG | ool-120-thread-1 | XMLConfigurator                  | 388 - org.apache.servicemix.bundles.opensaml - 3.2.0.1 | XMLObjectProviderRegistry did not exist in ConfigurationService, will be created
2016-06-21 16:29:10,488 | DEBUG | ool-120-thread-1 | ractXMLObjectProviderInitializer | 388 - org.apache.servicemix.bundles.opensaml - 3.2.0.1 | Loading XMLObject provider configuration from resource 'default-config.xml'
2016-06-21 16:29:10,489 | ERROR | ool-120-thread-1 | ractXMLObjectProviderInitializer | 388 - org.apache.servicemix.bundles.opensaml - 3.2.0.1 | Problem loading configuration resource
org.opensaml.core.xml.config.XMLConfigurationException: Resource not found
    at org.opensaml.core.xml.config.AbstractXMLObjectProviderInitializer.init(AbstractXMLObjectProviderInitializer.java:54)[388:org.apache.servicemix.bundles.opensaml:3.2.0.1]
    at org.opensaml.core.xml.config.XMLObjectProviderInitializer.init(XMLObjectProviderInitializer.java:45)[388:org.apache.servicemix.bundles.opensaml:3.2.0.1]
    at org.opensaml.core.config.InitializationService.initialize(InitializationService.java:56)[388:org.apache.servicemix.bundles.opensaml:3.2.0.1]

AbstractXMLObjectProviderInitializer正在按以下方式加载资源(resourcedefault-config.xml):

AbstractXMLObjectProviderInitializer is loading the resource as follows (resource is default-config.xml):

Thread.currentThread().getContextClassLoader().getResourceAsStream(resource)

default-config.xml位于(opensaml)jar的根中,这使我怀疑是否是找不到它的原因.

default-config.xml is located in the root of the (opensaml) jar which makes me wonder if that's the reason it cannot be found.

我在项目中使用maven-bundle-plugin,除了依赖项和opensaml类的各种用法外,我还为以下软件包提供了显式导入(Import-Package):

I'm using the maven-bundle-plugin in my project and on top of the dependency and various uses of opensaml classes I provided explicit imports (Import-Package) for the following packages:

org.opensaml.core.xml.config,
org.opensaml.saml.config,
org.opensaml.xmlsec.config,

捆绑商品清单中或其他地方缺少任何东西可以使这项工作有效吗?我认为servicemix本身发布的opensaml捆绑包应该可以按原样工作...

Is there anything I am missing in my bundle's manifest or elsewhere to make this work? I presume the opensaml bundle released by servicemix itself should be working as is...

推荐答案

我找到了资源未找到"问题的解决方案,但它比其他任何事情都更重要……

I found a solution to the "resource not found" issue but it's a hack more than anything...

绊倒SO帖子后更好地处理Thread Context ClassLoader OSGi 在调用它之前,我修改了代码以设置InitializationService的类加载器,现在可以在初始化期间找到有问题的XML.

After stumbling across the SO post Better handling of Thread Context ClassLoader in OSGi I adapted my code to set the classloader of the InitializationService before calling it, the XML in question is now found during initialization.

    // adapt TCCL
    Thread thread = Thread.currentThread();
    ClassLoader loader = thread.getContextClassLoader();
    thread.setContextClassLoader(InitializationService.class.getClassLoader());
    try {
        InitializationService.initialize();
    } finally {
        // reset TCCL
        thread.setContextClassLoader(loader);
    }

但是,我注意到捆绑中的SPI配置org.opensaml.core.config.Initializer尚未加载,我还没有找到适当的解决方案.我当前的解决方法是显式调用我需要的初始化程序的init方法:

However, I've noticed that the SPI config org.opensaml.core.config.Initializer in my bundle does not get loaded and I have not figured out a proper fix for that yet. My current workaround is explicitly calling the init methods of initializers I need:

  • org.opensaml.saml.config.XMLObjectProviderInitializer
  • org.opensaml.saml.config.SAMLConfigurationInitializer
  • org.opensaml.xmlsec.config.XMLObjectProviderInitializer
  • org.opensaml.saml.config.XMLObjectProviderInitializer
  • org.opensaml.saml.config.SAMLConfigurationInitializer
  • org.opensaml.xmlsec.config.XMLObjectProviderInitializer

请注意,以下各项也是必需的,但默认情况下会初始化(由于opensaml捆绑包中的SPI配置org.opensaml.core.config.Initializer-会被加载):

Mind that the following are required as well but get initialized per default (because of SPI config org.opensaml.core.config.Initializer in opensaml bundle - which does get loaded):

  • org.opensaml.core.xml.config.XMLObjectProviderInitializer
  • org.opensaml.core.xml.config.GlobalParserPoolInitializer
  • org.opensaml.core.xml.config.XMLObjectProviderInitializer
  • org.opensaml.core.xml.config.GlobalParserPoolInitializer

这篇关于在OSGi容器中找不到OpenSAML3资源'default-config.xml'的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-28 08:30