Importing 3rd party jar vcenter version incompatibility problem

[LMcManamon]

Hello,

I develop a vCenter plugin which imports 3rd party jar files. I've run into a vCenter version incompatibility. As of around either late 6.7u2 or 6.7u3, my plugin no longer registers successfully. I am unsure of what I need to do or change in order to get it working on these newer vCenter versions, and why it would only throw these errors on the newer versions. An example of the error is listed below.

vsphere_client_virgo.log:[2020-05-16T00:19:58.509Z] [ERROR] vc-extensionmanager-pool-235  com.vmware.vise.extensionfw.plugins.impl.PluginStatusServiceImpl DEPLOYMENT_FAILED: Error deploying plugin package com.hpe.vnsui:1.4.9.0. Reason: Deployment error. java.io.IOException: The bundle at /etc/vmware/vsphere-ui/vc-packages/vsphere-client-serenity/com.hpe.vnsui-1.4.9.0/plugins/httpcore-4.4.9.jar should have Bundle-SymbolicName and Bundle-Version headers in its MANIFEST.MF

Any help would be appreciated. Thank you.

[Plam_Dimitrov]

Hello,

From what I can gather from the log line the third-party jar you are trying to use (apache-httpcore?) is not a valid OSGi bundle - it does not contain the OSGi-specific headers in its MANIFEST.MF file (Bundle-SymbolicName, Bundle-Version, Import-Package etc.). How do you try to consume this jar - is it part of (embedded into) you service jar or is it deployed alongside it and then you try to Import-Package packages from it? If I interpret the log correctly, then the second option is implemented. This is bound to fail since, as already mentioned, the jar is not an OSGi bundle and hence it is not exporting the packages you are trying to import. If this was indeed working pre-6.7u2 then it may have been something that the Virgo server (replaced with our own implementation in 67u2) was providing and we may need to look at your plugin for further details.

Regards,

Plam

[LMcManamon]

Hello,

You are correct that we deploy the jar alongside it and then try to Import-Package packages from it. Would creating MANIFEST.MF files for all 3rd party jar files to make them into OSGI bundles potentially be a viable solution?

What specific files or information would I need to provide for the further look into the plugin?

Thank you,

Luke McManamon

[Plam_Dimitrov]

Hello Luke,

 

It is definitely possible - many of those jars have "OSGi-fied" versions out there that you can use. If not, there are tools to create your own OSGi bundles out of plain jars.

 

It'd peculiar if your plugin indeed hasn't changed and works like this before 6.7u2 since the Virgo server used there was also an OSGi container that worked with OSGi bundles (a possibility is that it worked because your service got wired to httpcore provided by Virgo instead of the one you are bringing). If you'd like us to look at your plugin and see what could have changed you can contact us at [e-mail] so we can arrange the plugin transfer.

 

Regards,

Plam

[LMcManamon]

I worked with vmware reps behind the scenes and were able to fix the issue. First, we needed to add bundle-classpath to the service layer manifest.mf file for the 3rd party jar files we were using. Then, rather than deploy it alongside our service jar, we packaged them into the root level of the service jar. This allowed our plugin to install on both newer and older version of vCenter.