将Cloudinary与Adobe AEM集成

Question

我正在尝试将Adobe AEM 6.3（运行在Java1.8）与Cloudinary SDK集成。我已经完成了以下操作，但是一直遇到一个我无法解决的异常。有人将Cloudinary与AEM集成并遇到类似的问题吗？

1. 在编译代码的pom.xml中添加依赖项。

<dependency>
  <groupId>com.cloudinary</groupId>
  <artifactId>cloudinary-core</artifactId>
  <version>1.24.0</version>  
</dependency>  
<dependency>
  <groupId>com.cloudinary</groupId>
  <artifactId>cloudinary-http44</artifactId>
  <version>1.24.0</version>         
</dependency>

构建一个OSGI插件，确保AEM获得正确的jar文件。为此，我按照以下步骤创建了一个第三方RESTful服务示例。为了构建捆绑包，我必须显式下载以下jar文件：cloudinary-1.0.14。jar，cloudinary-core-1.21.0。jar，cloudinary-http44-1.21.0。jar，commons-codec-1.10。jar，commons-collections-3.2.2。jar，commons-lang3-3.1。jar，commons-logging-1.2。jar，httpclient-4.4。jar，httpmime-4.4。jar，jsp-api-2.0。jar

尽管创建了一个包含httpclient的捆绑包，但在尝试将图像上传到Cloudinary时，我遇到了以下异常。下面是代码和例外。

代码片段

import com.cloudinary.*;
..
Cloudinary cloudinary = new Cloudinary("<<credentials>>");
...

File toUpload = new File("/Users/akshayranganath/Downloads/background-2633962_1280.jpg");

try {
  Map uploadResult = cloudinary.uploader().upload(toUpload, ObjectUtils.emptyMap());
} catch (IOException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
}

例外

Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/HostnameVerifier
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2370)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2154)
    at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
    at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
    at org.apache.http.impl.conn.SchemeRegistryFactory.createDefault(SchemeRegistryFactory.java:52)
    at org.apache.http.impl.client.AbstractHttpClient.createClientConnectionManager(AbstractHttpClient.java:321)
    at org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:484)
    at org.apache.http.impl.client.AbstractHttpClient.createHttpContext(AbstractHttpClient.java:301)
    at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:818)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
    at com.cloudinary.Uploader.callApi(Uploader.java:317)
    at com.cloudinary.Uploader.upload(Uploader.java:57)
    at com.aem.community.core.models.HelloWorldModel.init(HelloWorldModel.java:59)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.apache.sling.models.impl.ModelAdapterFactory.invokePostConstruct(ModelAdapterFactory.java:792)
    at org.apache.sling.models.impl.ModelAdapterFactory.createObject(ModelAdapterFactory.java:607)
    ... 211 common frames omitted
Caused by: java.lang.ClassNotFoundException: javax.net.ssl.HostnameVerifier not found by MyBundle [550]
    at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1574)
    at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
    at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
    ... 236 common frames omitted

这是我第一次与AEM合作，我可能没有遵循正确的步骤。请让我知道是否有人能够通过这个问题。

基于Alexander的建议和另一个源代码的指针，我向父级pom添加了以下代码。xml文件。

<plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <version>3.5.0</version>
    <configuration>
        <instructions>
        <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency>
        <Embed-Directory>OSGI-INF/lib</Embed-Directory>
        <Embed-Transitive>true</Embed-Transitive>
        </instructions>
    </configuration>
</plugin>

在做了这个更改之后，cloudinary库被添加到了包中。以下是AEM的输出：http://localhost:4502/system/console/bundles

Embedded-Artifacts: OSGI-INF/lib/cloudinary-http44-1.21.0.jar; g="com.cloudinary"; a="cloudinary-http44"; v="1.21.0", OSGI-INF/lib/commons-lang3-3.1.jar; g="org.apache.commons"; a="commons-lang3"; v="3.1", OSGI-INF/lib/httpclient-4.4.jar; g="org.apache.httpcomponents"; a="httpclient"; v="4.4", OSGI-INF/lib/httpcore-4.4.jar; g="org.apache.httpcomponents"; a="httpcore"; v="4.4", OSGI-INF/lib/commons-logging-1.2.jar; g="commons-logging"; a="commons-logging"; v="1.2", OSGI-INF/lib/commons-codec-1.9.jar; g="commons-codec"; a="commons-codec"; v="1.9", OSGI-INF/lib/httpmime-4.4.jar; g="org.apache.httpcomponents"; a="httpmime"; v="4.4", OSGI-INF/lib/cloudinary-core-1.21.0.jar; g="com.cloudinary"; a="cloudinary-core"; v="1.21.0"

但是，我现在得到一个错误与此消息：

org.apache.avalon.framework.logger -- Cannot be resolved
org.apache.log -- Cannot be resolved

我能够解析组织。阿帕奇。阿瓦隆。框架记录器错误，添加了对框架的依赖关系。但是，我无法忘记org。阿帕奇。日志问题。看起来是版本冲突导致了问题。

当我包含Cloudinary http p44库时，这个新错误就开始了。这个库看起来没有直接引用日志记录（有关依赖关系，请参见这里）。由于这个错误，应用程序仍然无法从安装状态转到活动状态。

Answer 1

Cloudinary-lib可以作为Maven工件提供。这样的JAR文件可以作为带有maven-bundle-plugin的私有库放在您的包中。

以下示例适用于我（即使使用Cloudinary测试帐户）

...
<plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <extensions>true</extensions>
    <executions>
        <execution>
            <!-- Create the bundle late in the compile-phase instead of the package-phase.
                 So the generated OSGi meta-data is available during JUnit tests. -->
            <id>run-before-tests</id>
            <phase>process-classes</phase>
            <goals>
                <goal>bundle</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <instructions>
            <Bundle-Name>Test Bundle</Bundle-Name>
            <Embed-Dependency>*;groupId=com.cloudinary;scope=compile|runtime</Embed-Dependency>
            <Embed-Directory>OSGI-INF/lib</Embed-Directory> <!-- not needed, but nice -->
            <Embed-Transitive>true</Embed-Transitive>
        </instructions>
    </configuration>
</plugin>
...

<dependencies>
    <dependency>
        <groupId>com.cloudinary</groupId>
        <artifactId>cloudinary-core</artifactId>
        <version>1.24.0</version>
    </dependency>
    <dependency>
        <groupId>com.cloudinary</groupId>
        <artifactId>cloudinary-http44</artifactId>
        <version>1.24.0</version>
    </dependency>
    ...

一般来说，嵌入外部库可能很简单、麻烦，甚至不可能。这取决于导入工件的依赖关系。

手动检查依赖关系树！（例如：。https://mvnrepository.com/)

你必须摆弄3个说明：

嵌入依赖项

这是图书馆，放在你的包里。小心使用星号操作符，否则你可能会包含太多的依赖项（在AEM的情况下，很容易将互联网的一半包含在内）。但不要包含太少！提取构建的包。jar，查看实际包含的内容（在cloudinary中很容易）。

进口包装

通常libs有太多的依赖关系，尤其是当libs来自另一个生态系统（如Spring或JEE容器），或者有很多半可选的依赖关系时。有了这个设置，你可以告诉OSGi，一个捆绑包可以被激活，即使某些依赖关系不可用。

这是一个真实的例子：

<Import-Package>
    !com.sun.msv.*,
    !org.apache.log4j.jmx.*,
    !sun.misc.*,
    !org.jboss.logging.*,
    !org.apache.zookeeper.*,
    *
</Import-Package>

出口包装

通常情况下，库应该是bundle私有的。但是有时你必须以不同的方式导入，或者lib会自动执行某些操作。所以你应该总是在系统控制台检查你的bundle正在导出什么。如果它不正确，你必须手动修改这个设置：

下面是一个例子：

<Export-Package>
    !*.internal,
    !*.internal.*,
    !*.impl,
    !*.impl.*,
    com.mycompany.myproject.mybundle.*
</Export-Package>

默认情况下，所有的包*都被导出，除了它们被命名为impl或内部。它们的子包也是私有的（！*. impl.*规则）。如果默认不起作用，那么只使用此指令导出您需要的。

无论导出什么，都会进入全局OSGi空间。此外，AEM和吊索捆绑包也不是完美的，也不是100%无缺陷的，请确保

• 开箱即用AEM捆绑包的启动/关闭顺序不应更改
• 代码的部署、重新部署或取消部署不应启动/停止任何现成的AEM捆绑包

如果不确保这一点，您可能会遇到奇怪的部署问题——这非常难以找到/解决。

所以最好的办法是，不要出口任何AEM开箱即用捆绑包进口的任何东西。其他一切都是专家专用的。甚至他们也高估了自己，低估了手动修补AEM的长期成本。

附言：_removeheaders指令可以删除运行时不需要的所有osgi指令。但是只有这样，如果你想向公众提供一个包并让它完全闪亮的话。我会把它留在里面，因为它是某种留档。