OSGi捆绑包无法启动-无法解析sun.reflect.generics.reflectiveObjects [英] OSGi bundles won't start - Unable to resolve sun.reflect.generics.reflectiveObjects

问题描述

在我的AEM项目的代码中看似无关紧要的更改之后，我的捆绑包无法解决.检查日志后，我看到出现以下错误.

After seemingly irrelevant changes in the code of my AEM project, my bundle fails to resolve. Upon inspecting the logs, I can see the following errors appearing.

22.04.2015 11:00:18.650 *ERROR* [qtp1266495948-35]
org.apache.felix.http.jetty %bundles.pluginTitle:
Cannot start (org.osgi.framework.BundleException:
Unresolved constraint in bundle my-bundle
...
[caused by: Unable to resolve 401.121: missing requirement [401.121]
osgi.wiring.package; (osgi.wiring.package=sun.reflect.generics.reflectiveObjects)]]

该项目在本地编译得很好，并且仅在容器尝试解决该捆绑包后，该问题才会出现.

The project compiles just fine locally and the problem only occurs after the bundle's installation when the container attempts to resolve it.

我没有在任何更改中添加任何显式依赖项.项目对象模型与以前相同.顾名思义，这是一个核心Java程序包，因此我希望它会被System捆绑包所公开.

I haven't added any explicit dependencies in any of my changes. The Project Object Models are the same as before. The name implies this is a core Java package so I'd expect it to be exposed by the System bundle.

我正在运行ADK支持的JDK 7，所以不要指望它与JVM兼容性有关.至少在涉及AEM内部方面.

I'm running JDK 7, which is supported by AEM so do not expect it to be a matter of JVM compatibility. At least when AEM internals are concerned.

推荐答案

包sun.reflect.generics.reflectiveObjects是JDK的一部分，但不是Java API的一部分，如

The package sun.reflect.generics.reflectiveObjects is part of the JDK but it's not part of the Java API, as explained in Oracle's documentation for Java 7 compatibility

sun.*软件包不属于受支持的公共界面. 不能保证直接调用sun.*包的Java程序可以在所有与Java兼容的平台上运行.实际上，即使在同一平台上的将来版本中，也不能保证此类程序可以工作.

The sun.* packages are not part of the supported, public interface. A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.

这说明了为什么AEM不将Apache Felix中的 System 捆绑包导出该软件包的原因.确实，这是一个非常合理的决定.代码在本地编译，因为该软件包位于我的类路径中，但在运行时失败，这一切都很好并且可以预期.

This explains why the package is not exported by the System bundle in Apache Felix, underlying AEM. A very reasonable decision indeed. The code compiled locally because the package was in my classpath but it failed at runtime, which is all fine and to be expected.

我的代码最初不应该使用此程序包.引入对这些程序包的依赖有两种可能的方法.

My code should not have been using this package in the first place. There are two possible ways of introducing a dependency on these packages.

1. 使用出于某些原因使用这些类的库，并引入可传递的依赖关系.这不是发生什么事.

1. Use a library that uses these classes for some reason and introduce a transitive dependency. This isn't what happened.

导入这些类之一-这是一件很愚蠢的事情.如果有人使用课程，他们应该知道它是什么.

Import one of these classes - a very silly thing to do. If someone uses a class, they should know what it is.

就我而言，我从该包中显式导入了一个类，而没有注意到它.

In my case, I explicitly imported a class from this package without noticing it.

事实证明，sun.reflect.generics.reflectiveObjects程序包包含一个NotImplementedException类，其名称与apache.commons.lang3中经常使用的NotImplementedException一致.

It turns out that the sun.reflect.generics.reflectiveObjects package contains a NotImplementedException class, the name of which coincides with the often-used NotImplementedException from apache.commons.lang3.

当它在我的IDE中自动完成时，我不小心将其导入，并且很长一段时间都没有注意到它.我花了git bisect来隔离更改.

I accidentally imported it when it was auto-completed in my IDE and failed to notice this for a long time. It took me a git bisect to isolate the change.

发生这种情况后，我从自动完成功能中排除了sun.*个程序包.

After this happened, I excluded the sun.* packages from autocomplete.

这篇关于OSGi捆绑包无法启动-无法解析sun.reflect.generics.reflectiveObjects的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！