VMware {code} Community
virat1234
Enthusiast
Enthusiast

"Resolver reported uses conflict for import" on vcenter 6.0 update 2

We were testing out extension that works fine with vcenter 5.5 and 6.0 update 1 and the vcenter 6.0 update 2 and noticed the following issue. Its hard to tell what is going on.

[2016-03-16T14:20:43.895-07:00] [ERROR] fs-watcher                    org.eclipse.virgo.medic.eventlog.default                         DE0002E Installation of bundle 'com.mycompany.service' version '4.0.0' failed. org.eclipse.vir

go.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'com.mycompany.service' at version '4.0.0': Cannot resolve: com.mycompany.service

    Resolver report:

        Uses violation: <Import-Package: com.vmware.vise.data.uri; version="0.0.0"> in bundle <com.mycompany.service_4.0.0[1458163243648]>

             Resolver reported uses conflict for import

        Uses violation: <Import-Package: com.vmware.vise.data.query; version="0.0.0"> in bundle <com.mycompany.service_4.0.0[1458163243648]>

             Resolver reported uses conflict for import

        at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:46)

        at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)

        at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessGraph(CompensatingPipeline.java:73)

        at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)

        at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62)

        at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41)

        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:359)

        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:185)

        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:140)

        at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:253)

        at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeployerFileSystemListener.java:225)

        at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeployerFileSystemListener.java:79)

        at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:380)

        at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:289)

        at org.eclipse.virgo.nano.deployer.hot.WatchTask.run(WatchTask.java:49)

        at java.lang.Thread.run(Unknown Source)

Reply
0 Kudos
9 Replies
virat1234
Enthusiast
Enthusiast

I found the root cause of the issue. We had a dependency on Jackson 2.3.2 and virgo already has Jackson 2.4.1. The data-services jar (which has the com.vmware.vise.data package) now depends on Jackson (some transitive dependency). My plugin service jar depends on data-services jar as well as Jackson. The issue is not the version but the fact that the Jackson jars included in Virgo (2.4.1) only have 3 of the 6 jars we need. But we provide all the jars of jackson (2.3.2). Because of this we are seeing the conflict.

Now I could just have my plugin package to include the extra 3 jars of Jackson of version 2.4.1 and it would work (I have tested it). But, my question to vmware is, in the future if you upgrade Jackson version (say 2.5.0, which are not compatible with 2.4.1), my plugin will fail to deploy again unless I include the extra 3 jars of Jackson matching the version on Virgo.

How do I get around this tricky problem??

Reply
0 Kudos
Peter_Ivanov
VMware Employee
VMware Employee

Hello,

I would recommend the following:

  • include all the Jackson jar files inside your bundle
  • Specify the in the Bundle-Classpath property in your MANIFEST.MF file like this
  • Remove all Jackson packages from the Import-Package
  • IMPORTANT: Make sure that you do not export any jackson packages from your bundle. If you use Eclipse Bundlor tool by default it will export them.

This way your plugin will work and will be independent of the Web Client's version of the Jackson binaries.

There is another approach - to specify the Jackson version in the Import-Package and deploy the version that you need. Virgo web server supports deploying multiple versions of one and the same bundle.

The problem with this approach is that your plugin can break other VMware or 3rd party plugins which import Jackson packages without version.

Hope this helps!

Reply
0 Kudos
virat1234
Enthusiast
Enthusiast

I did have Jackson version specified, but your com.vmware.vise.data package seems to have a transitive dependency on the Jackson version already present in Virgo. Because of this my service module fails to deploy as OSGI says there is a conflict of Jackson versions (VMware module uses 2.4.1 and my plugin wants 2.3.2,  and since my plugin depends on VMware modules, through transitive dependency, it has to use 2.4.1).

Also, this is not the only package problem. My service module was using Guava.18 and Virgo was using Guava.15. My manifest was specifically asking for guava.18, but other VMware modules were already using guava.15. My module failed to deploy here as well. For now I changed it to use any guava version 15 and above.

I will explore the bundle-classpath option and see if that is safer.


Reply
0 Kudos
dkfje
Enthusiast
Enthusiast

I'm having similar issue.  But this solution doesn't seem to fix it.  What should your MANIFEST.MF should look like?

Reply
0 Kudos
_vladi_
VMware Employee
VMware Employee

Hi,

This is explained in the FAQ which is part of the SDK deliverable (vsphere-client-sdk/docs/FAQ.html), section "How to use 3rd party java libraries?". Here is the paragraph that answers your question:

Notes: Here is how you can nest a 3rd party java library inside your own bundle in order to avoid conflicts with other bundles deployed on the server (i.e. this is a way to package your own dependencies):

  • Add this to your MANIFEST.MF 
    Bundle-ClassPath: .,myOtherLib.jar
    
  • Include myOtherLib.jar at the root level of your plugin jar. It will be searched by the class loader along with the other classes from your plugin.
  • If you generate the manifest with bundlor you may need to add a list of packages in Excluded-Imports: and Excluded-Exports: to be sure your plugin bundle doesn't export or import things that will interfere.

Cheers,

Vladimir

Reply
0 Kudos
dkfje
Enthusiast
Enthusiast

I tried to make the vsphere-client-lib.jar into a 3rd party jar so that I can use the Bundle-ClassPath but I'm getting this error:

config=osgibundle:/META-INF/spring/*.xml) org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'uriRefTypeAdapter'

tion of bean failed; nested exception is org.springframework.beans.TypeMismatchException: Failed to convert property value of type 'java.lang.String' to required type 'java.lang.Class[]' for property 'interfaces'; nested exception is java.lang.IllegalArgumentException: Cannot find class [com.vmware.vise.data.uri.ResourceTypeResolverRegistry]

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:527)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)

        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.MandatoryImporterDependencyFactory.getServiceDependencies(MandatoryImporterDependencyFactory.java:96)

        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyServiceManager.doFindDependencies(DependencyServiceManager.java:355)

        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyServiceManager.findServiceDependencies(DependencyServiceManager.java:294)

        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.stageOne(DependencyWaiterApplicationContextExecutor.java:251)

        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.refresh(DependencyWaiterApplicationContextExecutor.java:177)

        at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:157)

        at org.eclipse.gemini.blueprint.extender.internal.activator.LifecycleManager$1.run(LifecycleManager.java:211)

        at org.eclipse.virgo.kernel.agent.dm.ContextPropagatingTaskExecutor$2.run(ContextPropagatingTaskExecutor.java:95)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

Reply
0 Kudos
_vladi_
VMware Employee
VMware Employee

Putting vsphere-client-lib.jar itself inside your plugin is not recommended. Your plugin is supposed to be compiled against it not to package it.
Could you please specify more information about what initial problem you are trying to solve? If you could provide your MANIFEST.MF and vsphere_client_virgo.log with the initial error that would be great.

Thanks,

Vladimir

Reply
0 Kudos
dkfje
Enthusiast
Enthusiast

It's the same issue as the original post.  My plugin works fine using vSphere 6.0 but with update 2.  I'm getting this issue.

  1. [2016-03-16T14:20:43.895-07:00] [ERROR] fs-watcher                    org.eclipse.virgo.medic.eventlog.default                         DE0002E Installation of bundle 'com.mycompany.service' version '4.0.0' failed. org.eclipse.vir 
  2. go.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'com.mycompany.service' at version '4.0.0': Cannot resolve: com.mycompany.service 
  3.     Resolver report: 
  4.         Uses violation: <Import-Package: com.vmware.vise.data.uri; version="0.0.0"> in bundle <com.mycompany.service_4.0.0[1458163243648]> 
  5.              Resolver reported uses conflict for import 
  6.         Uses violation: <Import-Package: com.vmware.vise.data.query; version="0.0.0"> in bundle <com.mycompany.service_4.0.0[1458163243648]> 
  7.              Resolver reported uses conflict for import 
  8.  
  9.  
  10.         at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:46) 
  11.         at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62) 
  12.         at org.eclipse.virgo.kernel.install.pipeline.internal.CompensatingPipeline.doProcessGraph(CompensatingPipeline.java:73) 
  13.         at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41) 
  14.         at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessGraph(StandardPipeline.java:62) 
  15.         at org.eclipse.virgo.kernel.install.pipeline.stage.AbstractPipelineStage.process(AbstractPipelineStage.java:41) 
  16.         at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.driveInstallPipeline(PipelinedApplicationDeployer.java:359) 
  17.         at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:185) 
  18.         at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:140) 
  19.         at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:253) 
  20.         at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeployerFileSystemListener.java:225) 
  21.         at org.eclipse.virgo.nano.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeployerFileSystemListener.java:79) 
  22.         at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:380) 
  23.         at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:289) 
  24.         at org.eclipse.virgo.nano.deployer.hot.WatchTask.run(WatchTask.java:49) 
  25.         at java.lang.Thread.run(Unknown Source) 
Reply
0 Kudos
_vladi_
VMware Employee
VMware Employee

Hi,

As mentioned by virat1234 earlier, this shows up when your plugin depends on a library that is already deployed by Virgo but with a different version (in his case Jackson). Then your required version of this library will not be deployed, so you need to package it inside your bundle (the conflicting library jar, not vsphere-client-lib.jar).

First step for this is to discover which is the conflicting library. Just check what libraries you have in Import-Package and see if Virgo deploys other versions of those.

If you need more help with this please send your MANIFEST.MF or the Import-Package section from it. Please also mention which SDK version you are using.

Cheers,

Vladimir

Reply
0 Kudos