_vladi_'s Posts

Hi lily, I am guessing you are trying to extend the GlobalView sample plugin with WSSDK functionality. In that case it is important to know how _vimPort and svcInstanceRef are created and if they are valid so the thrown exception is required for troubleshooting. You can find the exception in the vsphere_client_virgo.log Please keep in mind the code in vsphere-wssdk-provider is applicable in the context of Web Client plugin architecture. If you want to create a standalone program (and not a plugin) to talk to vCenter, Web Client SDK will not help you - look at Web Services SDK instead. Cheers, Vladimir

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

Hi, The dev-setup scripts from 6.0.2 release now generate the ds.properties file. It still requires adding some properties manually as described in the 6.0.2 release notes. It should look like this: service.homeLdu = d5432fd0-dbe3-11e5-9f53-012356965cab solutionUser.keyAlias = vsphere-webclient solutionUser.keyStoreName = vsphere-webclient solutionUser.keyStorePath=C:/ProgramData/VMware/vSphere Web Client/store.jks (or /var/lib/vmware/vsphere-client/store.jks on MacOS) solutionUser.keyStorePassword=vmw@re lookupService=https://YOUR_VCENTER_IP/lookupservice/sdk Cheers, Vladimir

Thanks for the clarification. I have seen a similar problem which is most likely related to a few known issues with regards to SDK samples - specifically with the different flavors of chassis sample. All known issues with samples have been resolved with the recent 6.0.2 release of the Web Client SDK. Please try out the same scenario using the chassisB-html sample from SDK 6.0.2. If the issue is still reproducible please confirm the used versions of SDK, Web Client and vCenter and attach the vsphere_client_virgo.log if possible. Thank you.

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

Yes, that's correct. This is controlled by the following line in the sample's plugin-package.xml: <pluginPackage id="com.vmware.vsphere.client" version="6.0.0" /> Defined this way it means "the plugin is compatible by Web Client version 6.0.0 or above". Cheers, Vladimir

Hi Michael, You need to use SDK 5.5.1 or 5.5.2 if your target Web Client version is 5.5.x. Please download SDK version 5.5.2 from this page: https://developercenter.vmware.com/web/sdk/55/web-client and use the ChassisA sample from there. Cheers, Vladimir

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

Hi taipeifansho, You cannot override the default behavior but you can define your own for many operations on datacenters, hosts, vms, etc. It can be executed by a new action which is described in more details by the vmaction sample. Specific operations on datacenters, hosts, vms, etc. are handled by Web Services SDK (not Web Client SDK) which is documented here: http://pubs.vmware.com/vsphere-60/topic/com.vmware.wssdk.pg.doc/PG_Preface.html Web Services SDK is bundled as vim25.jar and delivered with the Web Client SDK. The WSSDK sample shows how you can use it from a Web Client SDK plugin. Hope this helps! Cheers, Vladimir

Hi Pankaj,   The cause of the issue is unresolved UserSessionService dependency. This service is not really used in this sample, so as a workaround you can remove the reference to it from globalview-service project.   This will be fixed in a new SDK release. Sorry for the inconvenience. Cheers, Vladi

Hi dsackinger, You are correct. This is a known bug in vSphere Web Client SDK 6.0 U1 and will be fixed in the next SDK release. No other versions are affected so you can safely use vim25.jar from the previous version (vSphere Web Client SDK 6.0). Cheers, Vladi