Развертывание моего проекта с S4 SDK в SCP Neo приведет к ошибке - PullRequest
Новая
       5

Развертывание моего проекта с S4 SDK в SCP Neo приведет к ошибке

0 голосов
/ 25 февраля 2019

Я хочу использовать S / 4 HANA SDK в моем существующем Java-проекте в SCP Neo.Мне посоветовали сгенерировать новый проект, а затем перенести существующий код в сгенерированный проект в приложении.Я сгенерировал новый проект с типом архитектора, указанным в шаге 2 руководства SAN 4 HANA, и скопировал существующий код в модуль приложения.Когда я попытался развернуть свое приложение в SCP Neo и попытался запустить его.Он не запустился, и в журнале SCP я увидел следующую ошибку.Посоветуйте, пожалуйста, как это исправить?(мой существующий также использует регистратор).

С уважением

Фред Z 

24 Feb 23:14:15 UTC - org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/s4scheduler-application]
2019 02 24 23:14:15#+00#ERROR#org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/s4scheduler-application]##anonymous#localhost-startStop-1#na#ogfigrvps3#s4schedulerapplication#web##na#na#na#na#Error configuring application listener of class [com.sap.cloud.sdk.s4hana.connectivity.ErpDestination] java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader "<unnamed>" (instance of org.apache.catalina.loader.ParallelWebappClassLoader@3b3235ca, child of java.net.URLClassLoader@61baa894) of the current class, org/slf4j/LoggerFactory, and the class loader "System" (instance of sun.misc.Launcher$AppClassLoader@277050dc, child of sun.misc.Launcher$ExtClassLoader@2b71fc7e, urls: 'file:/usr/lib/jvm/sapjvm_8/sapjvm_8/lib/jvmx.jar', 'file:/usr/lib/jvm/sapjvm_8/sapjvm_8/lib/tools.jar', 'file:/usr/sap/ljs/bin/jul-to-slf4j.jar', 'file:/usr/sap/ljs/bin/slf4j-api.jar', 'file:/usr/sap/ljs/bin/logback-classic.jar', 'file:/usr/sap/ljs/bin/logback-core.jar', 'file:/usr/sap/ljs/bin/logback-config/', 'file:/usr/sap/ljs/bin/com.sap.core.js.logging.jar', 'file:/usr/sap/ljs/bin/bootstrap.jar', 'file:/usr/sap/ljs/bin/tomcat-juli.jar') for the method's defining class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type org/slf4j/ILoggerFactory used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:418)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at com.sap.cloud.sdk.cloudplatform.logging.CloudLoggerFactory.<clinit>(CloudLoggerFactory.java:21)
at com.sap.cloud.sdk.cloudplatform.connectivity.DestinationDeclarator.<clinit>(DestinationDeclarator.java:29)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4714)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:985)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:836)

1 Ответ

0 голосов
/ 11 марта 2019

Решения

В зависимости от того, находится ли под вашим контролем some.other.group.id:some-other-artifact-id, у вас есть два варианта, предпочтительным является вариант 1.

  1. Если вы можете изменитьзависимости some-other-artifact-id, удалите все конкретные реализации регистратора с областями действия compile и provided и замените их на slf4j-api.При необходимости, например, для испытаний, вы можете использовать конкретные реализации в областях test или runtime.В общем, это лучшая практика для библиотек, поскольку библиотеки не могут знать, какой фактический регистратор используется в реальном приложении, построенном с библиотекой.

  2. Если у вас нет прямого контроля над зависимостями в some-other-artifact-id вы можете удалить зависимость, добавив следующее в dependencies блок вашего pom.xml: 

    <dependency>
    <groupId>some.other.group.id</groupId>
    <artifactId>some-other-artifact-id</artifactId>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Фон

Важная частьДерево зависимостей извлекается ниже: 

[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ some-application ---
[INFO] some.group.id:some-artifact-id:jar:1.0
...
[INFO] +- org.slf4j:slf4j-api:jar:1.7.25:compile
[INFO] +- org.slf4j:jcl-over-slf4j:jar:1.7.25:runtime
[INFO] +- some.other.group.id:some-other-artifact-id:jar:1.0:compile
...
[INFO] |  +- org.apache.httpcomponents:httpclient:jar:4.5.6:compile
[INFO] |  |  \- commons-logging:commons-logging:jar:1.2:compile
...

У вас есть зависимость jcl-over-slf4j и commons-logging от вашего пути к классам.Поскольку первый является «заменой» второго, теперь у вас есть два набора реализаций для одних и тех же классов, что приводит к ошибкам во время выполнения.

Дальнейшее чтение

...