This happens when you forget to compile your plugin resource files. String resources defined in main/locale/ must be compiled into .swf files because this is the format expected by the Client.
Yes, use the openModalDialog API
<?xml version="1.0" encoding="UTF-8"?>
<pluginPackage id="com.vmware.samples.pluginA" version="6.0.0" name="pluginA"
description="pluginA" vendor="VMware">
<dependencies>
<!-- Minimum vSphere Client version compatible with this plugin -->
<pluginPackage id="com.vmware.vsphere.client" version="5.5.1" />
<!-- Dependency on pluginB, i.e. pluginA won't be installed unless pluginB is present -->
<pluginPackage id="com.vmware.samples.pluginB" version="1.0.0" />
</dependencies>
<bundlesOrder>
<bundle id="com.google.gson" />
<bundle id="com.vmware.samples.plugina.service" />
<bundle id="com.vmware.samples.plugina" />
</bundlesOrder>
</pluginPackage>
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 unless it is very small and you are confident this won't 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 the vsphere-wssdk sample uses two external libraries: gson-2.0.jar and vim25.jar. Its plugin-package.xml lists those two libraries at the 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.wssdkprovider" />
<bundle id="com.vmware.samples.wssdkui" />
</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 in DataAccessController.getProperties(), while trying to retrieve data from vCenter, if the request started from a non-authenticated http session on the UI side. Check that your html view or action URL ends with .html, that format is required for the html UI to make calls to the server which rely on the current user session.
<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.5 uses Virgo version 3.6.4, 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 |
| Flex SDK dev setup (Mac or Windows) | flex-client-sdk/ server/serviceability/logs/vsphere_client_virgo.log |
| HTML client Fling OVA | /usr/lib/vmware-vsphere-client/server/serviceability/logs/ |
| vCSA 6.5 (HTML client) | /var/log/vmware/vsphere-ui/logs/ |
| vCSA 6.0 and 6.5 (Flex client) | /var/log/vmware/vsphere-client/logs/ |
| vCenter for Windows 6.0 and 6.5 (Flex client) | C:\ProgramData\VMware\vCenterServer\logs\vsphere-client\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 but don't add more info, so it is easier to use vsphere_client_virgo.log for everything. Notice that when you start Virgo on the command line the console contains only important messages. 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 error in the log.
After a severe errors 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: Getting Started with HTML Client SDK - Eclipse Setup - Extensions Points - Java API - Javascript API - Tutorial
