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)
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??
Hello,
I would recommend the following:
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!
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.
I'm having similar issue. But this solution doesn't seem to fix it. What should your MANIFEST.MF should look like?
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):
Bundle-ClassPath: .,myOtherLib.jar
Cheers,
Vladimir
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)
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
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.
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