VMware {code} Community
usernamealrea11
Contributor
Contributor

ClassCastException when registering plugin websocket endpoint

Our team is using SDK v6.7 update 3, and the following code:

    public void contextInitialized(ServletContextEvent sce) {
         final ServletContext servletContext = sce.getServletContext();
         final ServerContainer globalPassthru = (ServerContainer)servletContext.getAttribute("javax.websocket.server.ServerContainer");
         .
         .
     }    

Invariably throws a ClassCastException:

    com.vmware.o6jia.context.web.websocket.ServerContainerWrapper cannot be cast to javax.websocket.server.ServerContainer 

However, if the plugin is deployed in global scope, the code above works flawlessly. We've already attempted setting/resetting context classloader as described here:

    Thread.currentThread().setContextClassLoader(getClass().getClassLoader())

Does removing <code>scope="global"</code> from pluginPackage involve additional configuration?

Reply
0 Kudos
2 Replies
amarinov
VMware Employee
VMware Employee

Hi,

To clear things up: if you add scope="global" to your plugin-package.xml your plugin starts working and when you remove the scope="global" it stops working?

Did you try deploying and testing your plugin on other vCenter Server versions, what was the result?

Can you provide the full logs of vSphere UI server? If you are running a local vSphere UI server as part of the SDK artifact then the logs are located in "html-client-sdk\vsphere-ui\server\logs" on your local machine. If you are deploying your plugin directly on the vCenter Server then the logs are located in "/var/log/vmware/vsphere-ui" on your vCenter Server.

Thank you!

Reply
0 Kudos
usernamealrea11
Contributor
Contributor

if you add scope="global" to your plugin-package.xml your plugin starts working and when you remove the scope="global" it stops working?

That's right. Turns out, this was caused by a copy of websocket-api.jar bundled with the plugin.

The injected ServerContainerWrapper was instantiated by root class loader, and couldn't be cast to corresponding interface which was loaded by the plugin class loader.

Simply removing the shared library resolves this issue.

Reply
0 Kudos