VMware vSphere HTML Client SDK
Frequently Asked Questions
The short answer is no: you should not run just any java code in the Virgo app server!
Java service plugins must remain light-weight processes, i.e. used only as "pass-through" to communicate between the client and vCenter Server or other data sources. The Virgo server is not intended to run 3rd party business processes implemented as extensions. Typically a java service or Data adapter handles service calls and data requests from the client, and then dispatches them to another server, either to retrieve data or trigger some action. The service processing should be limited to preparing and dispatching the back-end call, and managing the results before returning to the client: in short there should be no risk of heavy CPU or RAM usage, thread blocking, or long delays for a response to the client. Any complex business logic should be done in a back-end server, any long operation should be implemented as a task (for instance you can create a vCenter task to represent your long operations).
Caching of data at the service level is not recommended as this might affect scalability.
Do not create thread pools in your Java service! Keep the processing to a minimum and pass off the real business process to your own back-end.
Absolutely! Your Java service or DataProviderAdapter classes must be able to handle different threads. They are created as Spring beans so use the Singleton pattern by default. You should keep them stateless or treat concurrency carefully.
Your java plugin can use 3rd party jars if they are packaged as OSGI bundles (i.e. contain the correct OSGI metadata in order to be installed by the Virgo server) or are nested inside the plugin's bundle. The OSGI metadata is defined in MANIFEST.MF and includes the package names exported by the library, under Export-Packages. In turn your java plugin's manifest must list the 3rd party's packages it uses in Import-Packages, so that Virgo can establish dependencies between your bundle and the 3rd party jars.
Libraries packaged as OSGI bundles should be in a location known to the server:
For instance, if your plugin depends on two external libraries like gson-2.0.jar and vim25.jar, its plugin-package.xml should list the names of these two libraries at the very top of <bundlesOrder>:
...
<bundlesOrder>
<!-- vim25 and gson are loaded first to satisfy dependencies -->
<bundle id="com.vmware.wsvim25" />
<bundle id="com.google.gson" />
<bundle id="com.vmware.samples.pluginservice" />
<bundle id="com.vmware.samples.pluginui" />
</bundlesOrder>
It is very important to specify the version number of the libraries you are importing in the Import-Package section of MANIFEST.MF, like this (Version 0 is used to indicate packages which don't have a version):
Import-Package: org.apache.commons.logging;version="1.1.1", com.vmware.vise.data;version="0", com.vmware.vise.data.query;version="0", com.vmware.vise.usersession;version="0", com.vmware.vise.security;version="0", com.vmware.vise.vim.data;version="0", com.vmware.vim25;version="6.5.0", com.google.gson;version="2.3.1", javax.servlet.http;version="3.0", javax.net.ssl;version="0", org.springframework.beans.factory.annotation;version="3.1.4", org.springframework.http;version="3.1.4", org.springframework.stereotype;version="3.1.4", org.springframework.web.bind.annotation;version="3.1.4"
In some cases a library that you need is already available in server/repository/usr as part of Virgo standard installation. In other cases you may want to use a different version than the one installed with Virgo. As long as you specify the version the correct library will be loaded by your plugin's class loader, it won't interfere with other bundles that may be using a different version, this is one of the advantages of OSGI.
Note: nesting a 3rd party java library inside your own bundle to avoid conflicts.
Instead of using the 3rd party library as an OSGI package you can include it inside your own bundle and make it visible only to your java service. This is a way to package your own dependencies and avoid conflicts with other bundles deployed on the server:
Bundle-ClassPath: .,myOtherLib.jarInclude 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.
The recommended way is to integrate bundlor with your Ant or Maven build as explained in the documentation. However if you want to transform quickly a 3rd party library (e.g. foo.jar) follow these 2 steps:
Bundle-ManifestVersion: 2 Bundle-SymbolicName: com.company.foo Bundle-Name: Foo Bundle-Vendor: myCompany Bundle-Version:1.0.0
%BUNDLOR_HOME%\bin\bundlor.bat -i foo.jar -m template.mf -o foo-1.0.0.jar
com.vmware.vise.vim.commons.security.NotAuthenticatedError: The session is not authenticated.That exception occurs while trying to retrieve data from the vCenter Server, if the request started from a non-authenticated http session on the UI side. Make sure that your code is using the latest session data by listening for sessionEnded notifications and not doing any session caching.
<body oncontextmenu="return false;">
For more technical information on Virgo please see the Virgo FAQ or the various docs at http://www.eclipse.org/virgo. vSphere Client 6.7 uses Virgo version 3.7.2, whose documentation can be downloaded here.
Do not modify the Virgo configuration unless you are sure that your change won't impact the normal behavior of vSphere Client.
The server log vsphere_client_virgo.log location depends on your setup:
| Environment | Virgo logs location |
|---|---|
| SDK dev setup (Mac or Windows) | html-client-sdk/vsphere-ui/server/serviceability/logs/vsphere_client_virgo.log |
| vSphere HTML Client Fling OVA | /usr/lib/vmware-vsphere-client/server/serviceability/logs/ |
| vCenter Server Appliance (vSphere Client) | /var/log/vmware/vsphere-ui/logs/ |
vsphere_client_virgo.log is a rolling log that you can configure differently following the Virgo documentation. The other logs under sub-directories of server/serviceability/logs are specific to different components providing a better overview of a particular topic. If you are uncertain about the area of interest it is preferred to use vsphere_client_virgo.log. Notice that when you start Virgo on the command line the console contains only important messages from the eventlog.log. You have to refer to the main file vsphere_client_virgo.log for the complete log.
Problems usually start with tags [ERROR] or [WARN ] in vsphere_client_virgo.log. To spot issues with your own plugin search your package id or bundle SymbolicName.
To increase the log level to DEBUG for a particular package add this logger (change "com.vmware" to your package) and make sure to start the server in Debug mode:
<logger level="DEBUG" additivity="false" name="com.vmware"> <appender-ref ref="SIFTED_LOG_FILE" /> <appender-ref ref="LOG_FILE" /> </logger>
The Eclipse server console will show each bundle being deployed or undeployed. It should also show deployment errors although you can refer to the full logs for more details. Another way to check the bundles status is through the Bundle Overview tab of the Virgo editor. Refresh the bundles list and select the bundle of your choice: the right-hand side displays its MANIFEST information and let you search exported and imported packages.
If you can't find the 3rd party library you added and were hoping to see in the Bundle Overview tab it is either because you didn't put it in the right place or it is not OSGI-compliant, see the section How to use 3rd party libraries?. If you can't find your own plugin bundle in the Virgo list, or don't see the expected Imported or Exported packages for that bundle, first check that your latest changes have been saved to the server, then check that were there were no deployment errors in the log.
After a severe error you may see a message in the Virgo console that a dump file was generated but the corresponding dump folder is empty. This is because dump generation is disabled by default as those files tend to be very large. You can restore dump generation by commenting out the dump.exclusions flags in server/configuration/org.eclipse.virgo.medic.properties, i.e. adding # in front of each line and restarting Virgo.
Check that the VMware vSphere Client service is not running already on the same machine (case where you have installed vSphere Client on your development machine with the Windows installer and didn't stop the service).
Another possible reason could be that a previous Virgo session wasn't terminated properly and that process is still running. You can see that either in Eclipse's Debug view (in which case it's easy to kill there) or in your machine's Task Manager (look for a Java process).
See also: Javascript API - Java API - FAQ
