两个捆绑包之间的OSGi doPrivileged调用

Question

我在使用OSGi时遇到问题。

我有的：

• 2个简单的捆绑包（捆绑包A称为捆绑包B）
• 蓝图用法
• OSGi安全性使用
• 这两个捆绑包都是具有所有权限的核心捆绑包
• 第三方捆绑软件没有所有权限，即PropertyPermission（“ bla”，“ write”）将被拒绝

因此，正如已经提到的，bundle调用非常简单。 捆绑软件A调用捆绑软件B。其中唯一复杂的事情是，该调用是doPrivileged调用。

以下方案/示例：

在没有doPrivileged的包A中设置“ bla”属性->失败（确定）

public void foo() {
 System.setProperty("bla", "blubb"); // throws java.security.AccessControlException: access denied ("java.util.PropertyPermission" "bla" "write") -> ok
}

使用doPrivileged-> works在捆绑软件A中设置“ bla”属性（确定）

public void foo() {
 AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
    @Override
    public Boolean run()
       throws Exception
    {
       System.setProperty("bla", "blubb"); // sets the bla property without throwing an exception -> ok
       return null;
    }
 });
}

现在尝试使用捆绑软件A的doPrivileged调用在捆绑软件B中设置“ bla”属性->失败（为什么？）

套装A：

public void foo() {
 AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() {
    @Override
    public Boolean run()
       throws Exception
    {
       // calls Bundle B
       bundleBService.bar();
       return null;
    }
 });
}

套装B：

public void bar() {
  System.setProperty("bla", "blubb"); // throws java.security.AccessControlException: access denied ("java.util.PropertyPermission" "bla" "write")
}

那么，为什么不能使用捆绑软件A的doPrivileged调用在捆绑软件B中设置属性？ 我希望doPrivileged调用也可以在这里工作。 为什么不呢？ 是使用蓝图的错吗？ 并且可以在不将bundleB方法添加doPrivileged块的情况下解决此问题吗？

更新：这是StackTrace：

java.security.AccessControlException: access denied ("java.util.PropertyPermission" "bla" "write")
    at java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
    at java.security.AccessController.checkPermission(AccessController.java:559)
    at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
    at java.lang.System.setProperty(System.java:782)
    at barpkg.BundleB.bar(BundleB.java:35)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
    at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
    at com.sun.proxy.$Proxy111.bar(Unknown Source)
    at foopkg.BundleA$1.run(BundleA.java:73)
    at foopkg.BundleA$1.run(BundleA.java:65)
    at java.security.AccessController.doPrivileged(Native Method)
    at foopkg.BundleA.foo(BundleA.java:65)
    at testpkg.PrivilegedTest.testDoPrivileged(PrivilegedTest.java:135)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
    at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67)
    at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
    at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:111)
    at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:84)
    at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:72)
    at org.ops4j.pax.exam.glassfish.GlassFishTestContainer.call(GlassFishTestContainer.java:271)
    at org.ops4j.pax.exam.spi.reactors.SingletonStagedReactor.invoke(SingletonStagedReactor.java:113)
    at org.ops4j.pax.exam.spi.reactors.PerSuiteStagedReactor.invoke(PerSuiteStagedReactor.java:47)
    at org.ops4j.pax.exam.junit.PaxExam$2.evaluate(PaxExam.java:294)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:111)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:242)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:137)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
    at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
    at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

我猜这行可能是麻烦制造者：

at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:54)
at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:119)
at com.sun.proxy.$Proxy111.bar(Unknown Source)

我将尝试不使用蓝图进行此调用，也将发生什么。 但是，如果蓝图是问题所在，我可以以某种方式处理它而不更换它吗？

谢谢

Answer 1

好的，现在也可以使用aries蓝图框架了。

我已经手动签名了白羊星座蓝图，代理和utils jar（所以它们也是核心包），以查看这是否可以解决问题。 很好

现在，我将创建一个Maven模块，在其中放置所需的所有蓝图包。 因此，我可以签名此捆绑包，而不必分别签名每个jar，也只需部署一个捆绑包即可。