Статьи

Mule ESB и исключение NoSuchMethodError: org.mule.util.ClassUtils.getClass

Сентябрь 15, 2018

В настоящее время я добавляю некоторые
функциональные возможности, связанные с SAML, в реализацию Mule3 одного из наших клиентов. Для работы с объектами SAML я использую
библиотеку OpenSAML, которая предоставляется
здесь как открытый исходный код.

Я добавил следующие зависимости в свой pom.xml, чтобы он работал:
 

<!-- SAML dependencies -->
<dependency>
  <groupId>org.opensaml</groupId>
  <artifactId>opensaml</artifactId>
  <version>2.5.1-1</version>
</dependency>
<dependency>
  <groupId>joda-time</groupId>
  <artifactId>joda-time</artifactId>
  <version>2.1</version>
</dependency>
<dependency>
  <groupId>org.opensaml</groupId>
  <artifactId>openws</artifactId>
  <version>1.4.2-1</version>
</dependency>
<dependency>
  <groupId>org.opensaml</groupId>
  <artifactId>xmltooling</artifactId>
  <version>1.3.2-1</version>
  <exclusions>
    <exclusion>
      <artifactId>log4j-over-slf4j</artifactId>
      <groupId>org.slf4j</groupId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.7.2</version>
</dependency>

Однако после добавления этих зависимостей и запуска теста с экземпляром Mule я получил следующее исключение:

java.lang.NoSuchMethodError: org.mule.util.ClassUtils.getClass (Ljava / lang / String; Z) Ljava / lang / Class;
в org.mule.util.ClassUtils.initializeClass (ClassUtils.java:356)
в org.mule.lifecycle.NotificationLifecycleObject. (NotificationLifecycleObject.java:45)
в org.mule.lifecycle.phases.MuleContextStopPhase .:lePhase .66 Mule )
в org.mule.lifecycle.phases.MuleContextStopPhase (MuleContextStopPhase.java:56).
на org.mule.lifecycle.RegistryBrokerLifecycleManager.registerPhases (RegistryBrokerLifecycleManager.java:43)
в org.mule.lifecycle.RegistryLifecycleManager (RegistryLifecycleManager.java.: 57)
на org.mule.lifecycle.RegistryBrokerLifecycleManager. (RegistryBrokerLifecycleManager.java:33)
в org.mule.registry.AbstractRegistryBroker. (AbstractRegistryBroker.java:37)
в org.mule.registry.DefaultRegistryBroker. (DefaultRegistryBroker.java:27)
в орг .mule.DefaultMuleContext.createRegistryBroker (DefaultMuleContext.java:159) по
адресу org.mule.DefaultMuleContext. (DefaultMuleContext.java:150)
по
адресу org.mule.context.DefaultMuleContextBuilder.utext.uudeuteuuM .DefaultMuleContextFactory.buildMuleContext (DefaultMuleContextFactory.java:199)
в org.mule.context.DefaultMuleContextFactory.doCreateMuleContext (DefaultMuleContextFactory.java:189)
на org.mule.context.DefaultMuleContextFactory.createMuleContext (DefaultMuleContextFactory.java:75)
в org.mule.tck.AbstractMuleTestCase.createMuleContext (AbstractMuleTestCase.java:520)
в org.mule.tck.AbstractMuleTestCase.setUp (AbstractMuleTestCase.java:446 )
в junit.framework.TestCase.runBare (TestCase.java:132)
в org.mule.tck.AbstractMuleTestCase.runBare (AbstractMuleTestCase.java:301)
в junit.framework.TestResult $ 1.Protect (TestResult.java:110)
в junit.framework.TestResult.runProtected (TestResult.java:128)
в junit.framework.TestResult.run (TestResult.java:113)
в junit.framework.TestCase.run (TestCase.java:124)
в org.mule.tck .AbstractMuleTestCase.run (AbstractMuleTestCase.java:280)
в junit.framework.TestSuite.runTest (
TestSuite.java:232)
в junit.framework.TestSuite.run (TestSuite.java:227)
в org.junit.internal.runners.JUnit38ClassRunner.run (JUnit38jlassRun) org.apache.maven.surefire.junit4.JUnit4Provider.execute (JUnit4Provider.java:264)
в org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet (JUnit4Provider.java:15.aref. orve. orma
. junit4.JUnit4Provider.invoke (JUnit4Provider.java:124)
в sun.reflect.NativeMethodAccessorImpl.invoke0 (собственный метод)
в sun.reflect.NativeMethodAccessorImpl.invoke (собственный
путь Java: 25)
в java.lang.reflect.Method.invoke (Method.java:597)
в org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2 (ReflectionUtils.java:208)
в org.apache.maven.surefire.booter.Pider $ ProviderProxy.invoke (ProviderFactory.java:158)
в org.apache.maven.surefire.booter.ProviderFactory.invokeProvider (ProviderFactory.java:86)
в org.apache.maven.surefire.booter.ForkedBooter.rcess.ork : 153)
at org.apache.maven.surefire.booter.ForkedBooter.main (ForkedBooter.java:95).

Это было странно, потому что я не ожидал, что библиотеки OpenSAML будут влиять на пакет org.mule.util! Погуглив вокруг я обнаружилчто исключение вызвано, когда более старая версия Apache commons-lang помещается в путь к классам. Таким образом, исключив эту зависимость из проекта, проблема была исправлена: 

<dependency>
  <groupId>org.opensaml</groupId>
  <artifactId>opensaml</artifactId>
  <version>2.5.1-1</version>
  <exclusions>
    <exclusion>
      <artifactId>commons-lang</artifactId>
      <groupId>commons-lang</groupId>
    </exclusion>
  </exclusions>
</dependency>

Очень жаль, что в сообщении говорится, что с библиотеками Mule что-то не так. При этом исключении «commons-lang-2.1.jar» добавляется не в путь к классам, а в «commons-lang-2.4.jar», который, как ожидается, будет доступен Mule.

30
Share: