Home > Virtualization > Setting Up vSphere Web Client SDK: A Few Mistakes to Avoid

Setting Up vSphere Web Client SDK: A Few Mistakes to Avoid

December 10th, 2013 Leave a comment Go to comments

With the vSphere Web Client, VMware has really made the system complicated and slower. The extension mechanism is more flexible, but forces developers to use more libraries/frameworks/languages, therefore represents a much deeper learning curve than before with the Web based plugins. Installing and configuring the development environment itself could be intimidating for some developers. That is why I wanted to avoid it as long as possible, until I got a consulting project that may involve developing plugin for the Web Client.

Over the Thanksgiving long weekend, I went through the installation and configuration, and finally got the hello world plugin up running. Here are a few pitfalls I got into. Hope you can avoid these by reading my blog. Due to the variance of environments, you may or may not see these for your installation. As always, it doesn’t hurt.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


Which installation guide?

Although I watched some of the videos on youtube and the presenter has done a good job in explaining the process, I still think the setup guide coming with the SDK is the best of all. The video is nice but not really consistent with the setup guide. For example, the advice on the installation path is not practical. I was also surprised to see the video suggested to type in certificate thumbprint (much longer than credit card numbers) while there is actually a handy batch command to get it done quickly, and more importantly, error free.

Enough being said. Just remember to read the setup guide coming with the SDK. Becauase the setup guide has done a very decent job, I am not going to repeat it here but focus on the issues that happened to me.

Eclipse 32 bits ONLY!

Limited by Flash Builder, which only supports 32 bits, you want to download 32 bit Eclipse Java EE. As I had Eclipse Indigo 64 bit already installed, I wanted to re-use it for developing Web Client plugin and only found it’s not feasible.

You can also use Spring Tool Suite (a.k.a. STS), but I decided not to go that route because Eclipse is used a lot more than STS, and the chance of bugs is supposedly much less. Also, I don’t use anything in Spring framework therefore STS is not useful to me.

Because the integration with Web server is needed, you want to install Eclipse Java EE not the classic Eclipse.

Zest package

By default GEF (Graphical Editing Framework) is not installed in Eclipse, but its zest package is required by vSphere Web Client SDK. Without it, installation of the Virgo Tools fails. In the Eclipse Indigo update site, just search zest and you’ll get GEF. Install GEF first and then installation of Virgo Tools succeeds. It’s possible that STS has zest package included, so you won’t get this problem. I have not tried STS so I am not quite sure about it. If you have experience there, feel free to share it.

JRE version caused no such algorithm exception

When everything started to work, I got the Web Client from local host in a browser. It was pretty exciting! After entering the user name and password, the authentication failed with an interesting error message on the login page. Digging down to the log, I found the following exception stack (trimmed to fit into this blog):

http-bio-9443-exec-9         0407D3EF13205AD340B17CE06D289C2F c.v.v.s.c.impl.SecurityTokenServiceImpl$RequestResponseProcessor  Cannot sign request message com.vmware.vim.sso.client.impl.exception.SignatureException: Error while creating SOAP request signature
       at com.vmware.vim.sso.client.impl.signature.WsSecuritySignatureImpl.sign(WsSecuritySignatureImpl.java:140)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
       at java.lang.Thread.run(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: unsupported algorithm
       at org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory.newSignatureMethod(Unknown Source)
       at com.vmware.vim.sso.client.impl.signature.WsSecuritySignatureImpl.getSignatureMethod(WsSecuritySignatureImpl.java:217)
       at com.vmware.vim.sso.client.impl.signature.WsSecuritySignatureImpl.sign(WsSecuritySignatureImpl.java:113)
       ... 91 common frames omitted

What is interesting is that it seems nothing to do with the SDK, but the SSO (Single Sign On). The log does not disclose what algorithm it did not find. Given my experience, I thought it’s related to Virgo and Java Runtime, but was not sure which caused the problem exactly. So I decided to switch the JRE (1.6.0_7) to a different and newer version of JRE (1.6.0_27). Luckily, the problem went away after the switch.

vCenter time sync

After the above SSO problem, another one came up. This time it’s related to the time difference of my client and vCenter server. Somehow, my vCenter appliance time shifted and when the client gets a SSO ticket it’s expired because there is a short time window for SSO tickets. I think it won’t be a problem if the plugin is deployed to the vCenter. By then the SSO code would run on the same machine as vCenter. Whatever the time shift, the SSO and vCenter have the same time therefore no problem at all.

The solution is quite straight forward. Just run the following commands with a SSH session to the vCenter appliance.

# sntp -P no -r

The NTP server is a public NTP server from NIST Web site. You can pick other servers or use your own NTP server.

If you want to make the change permanent, you can run the following. As I am a rushing hacker, I didn’t try it myself.

# yast2 ntp-client add server=<NTP_server>
# yast2 ntp-client enable

.mxml and .as source cannot be opened

After the first hello world plugin worked, I started to make a tiny change to the plugin. A change from the “hello world” text to “hello doublecloud” is simple enough but also good enough to make sure the development setup works end to end.

To make the change, I needed to use the IDE but .mxml file cannot be opened due to NullPointerException. It seems to be a bug, which I found a patch from the Internet here. Although it’s for Flash Builder 3.x (it was called Flex Builder by then?), it still works for 4.6 as I tried it. Just unzip it into your plugin directory and restart the Eclipse. With the IDE editor working, the above change is too trivial to discuss more here.


Overall I think the SDK is a bit too complicated for its purpose. Given VMware’s acquisition of SpringSource, it also wants to push in tools and components that are not necessary and not commonly used, like Spring Tool Suite, Virgo server, etc.

The good news is that it works after going through the pain. As I checked the related VMware Community Forum (), the engineers like Laurent are pretty active in answering the questions and helping the community. This is a big plus for sure.

  1. December 10th, 2013 at 05:52 | #1

    A valuable resource – seen a few of these mistakes before.

  2. Bhrami
    January 6th, 2014 at 14:12 | #2

    Were you able to load the ViJava.jar on the Virgo server? If yes, can you please document the steps you followed to do so. Thanks!

  3. January 8th, 2014 at 00:22 | #3

    I think it should be OK even though I haven’t done it. When I have time, I can probably give it a try and document it.


  4. Pankaj Chhabra
    October 3rd, 2015 at 00:01 | #4

    I am also running into issues with 64 bit, what were the versions of various products that you used. I am seeing some issues with vSphere Web SDK Update 2 as well. Please let me know the versions you used.

  5. October 3rd, 2015 at 00:08 | #5

    Hi Pankaj,

    Sorry that I don’t remember exactly all the versions I used. But the Eclipse, it’s Eclipse Indigo. For the vSphere Web SDK, I think it’s 5.5.

    Good luck!

    PS. if you have found out more, pls feel free to leave comments with more details.

  1. No trackbacks yet.