Jclouds с несколькими провайдерами

Я пытаюсь использовать Jclouds в своем приложении таким образом, чтобы оно могло работать с несколькими провайдерами одновременно. В частности, я пытаюсь использовать провайдера «openstack-nova» и провайдера «rackspace-cloudservers-us», чтобы я мог предоставлять узлы в двух разных облаках во время выполнения. Тем не менее, похоже, что провайдеры топчут друг друга; когда я включаю обе зависимости в свою сборку Maven, поставщик Rackspace является единственным доступным в списке поставщиков:

  <dependency>
    <groupId>org.apache.jclouds.provider</groupId>
    <artifactId>rackspace-cloudservers-us</artifactId>
    <version>1.7.0</version>
  </dependency>
  <dependency>
    <groupId>org.apache.jclouds.api</groupId>
    <artifactId>openstack-nova</artifactId>
    <version>1.7.0</version>
  </dependency>

Комментирование зависимости поставщика Rackspace позволит openstack-nova работать. Нет ли способа иметь несколько провайдеров с Jclouds одновременно?


person monitorjbl    schedule 10.02.2014    source источник


Ответы (2)


Это должно работать отлично. Вы должны иметь возможность создать контекст, передав «rackspace-cloudservers-us» в ContextBuilder или «openstack-nova» (на самом деле openstack-nova является транзитивной зависимостью от поставщика стоечного пространства, поэтому вы будете иметь его в пути к классам даже если вы явно не объявляете это). Какие конкретно проблемы у вас есть?

person Ignasi Barrera    schedule 16.07.2014

Я понял это, но забыл, что задавал этот вопрос. Вот что произошло.

Провайдеры jClouds регистрируются в Java ServiceLoaders. Это означает, что в каталоге META-INF/services есть небольшой файл с именем класса провайдера, который ядро ​​jClouds внедряет во время выполнения. Я делал толстый JAR с Shade, а это означало, что содержимое этого файла было перезаписано в финальном JAR.

Это оставило одну запись вместо двух, поэтому во время выполнения jClouds не мог найти другого поставщика. Мне пришлось добавить параметр конфигурации, чтобы Шейд не растоптал этот файл. Это то, что я уже делал для Spring, поэтому, как только я понял, что делает jClouds, это было довольно просто исправить.

Вот как выглядела моя конфигурация плагина для всех, кому любопытно:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <executions>
      <execution>
        <phase>package</phase>
        <goals>
          <goal>shade</goal>
        </goals>
        <configuration>
          <createDependencyReducedPom>false</createDependencyReducedPom>
          <transformers>
            <!--Need to do this to make sure spring schemas dont stomp on each other-->
            <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
              <resource>META-INF/spring.handlers</resource>
            </transformer>
            <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
              <resource>META-INF/spring.schemas</resource>
            </transformer>
            <!-- Need to make sure jClouds providers play nicely -->
            <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
              <resource>META-INF/services/org.jclouds.apis.ApiMetadata</resource>
            </transformer>
            <!--Executable JAR-ify this-->
            <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
              <mainClass>com.example.Main</mainClass>
            </transformer>
          </transformers>
        </configuration>
      </execution>
    </executions>
  </plugin>
person monitorjbl    schedule 17.07.2014