NPE in starting up a plugin

[royling]

I can see the following exceptions in the vsphere_client_virgo.log, but failed to reproduce it in my local virgo server...

java.lang.Exception: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ClusterPropertyProvider': Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ClusterPropertyProvider': FactoryBean threw exception on object creation; nested exception is java.lang.NullPointerException

        at com.vmware.vise.extensionfw.impl.BundleLifeCycleListenerImpl.onStartFailed(BundleLifeCycleListenerImpl.java:92)

        at org.eclipse.virgo.kernel.install.artifact.internal.StandardArtifactStateMonitor.onStartFailed(StandardArtifactStateMonitor.java:242)

        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.asyncStartFailed(AbstractInstallArtifact.java:329)

        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.access$1(AbstractInstallArtifact.java:325)

        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact$StateMonitorSignal.signalFailure(AbstractInstallArtifact.java:264)

        at org.eclipse.virgo.kernel.deployer.core.internal.AbortableSignalJunction.subSignalFailed(AbortableSignalJunction.java:103)

        at org.eclipse.virgo.kernel.deployer.core.internal.AbortableSignalJunction.access$1(AbortableSignalJunction.java:89)

        at org.eclipse.virgo.kernel.deployer.core.internal.AbortableSignalJunction$SubSignal.signalFailure(AbortableSignalJunction.java:155)

        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.signalFailure(AbstractInstallArtifact.java:297)

        at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact$StateMonitorSignal.signalFailure(AbstractInstallArtifact.java:270)

        at org.eclipse.virgo.nano.core.internal.BundleStartTracker$1.run(BundleStartTracker.java:142)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

        at java.lang.Thread.run(Thread.java:748)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ClusterPropertyProvider': Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ClusterPropertyProvider': FactoryBean threw exception on object creation; nested exception is java.lang.NullPointerException

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1634)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)

        at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)

        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)

        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:742)

        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)

        at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:57)

        at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:322)

        at org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)

        at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:287)

        at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:137)

        at org.eclipse.virgo.kernel.agent.dm.ContextPropagatingTaskExecutor$2.run(ContextPropagatingTaskExecutor.java:95)

        ... 3 common frames omitted

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ClusterPropertyProvider': FactoryBean threw exception on object creation; nested exception is java.lang.NullPointerException

        at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:185)

        at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:137)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1640)

        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:254)

        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)

        at org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean.afterPropertiesSet(OsgiServiceFactoryBean.java:185)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1692)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1630)

        ... 17 common frames omitted

Caused by: java.lang.NullPointerException: null

        at org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean.getObject(OsgiServiceFactoryBean.java:406)

        at org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean.getObject(OsgiServiceFactoryBean.java:72)

        at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:178)

        ... 24 common frames omitted

After spending several hours to figure out what could be the root cause, I gave up finally...

Can anyone help here? any insights?

the remote VCSA is at 6.7.0.200, the spring bundles are at version 4.3.17

My local client SDK is at a different version, the spring bundles are version 4.3.9 instead... could this be the problem?

Thanks!

[royling]

The exact lines where the exception was thrown is:

spring-framework/AbstractAutowireCapableBeanFactory.java at v4.3.17.RELEASE · spring-projects/spring-framework · GitHub

and

gemini.blueprint/OsgiServiceFactoryBean.java at 2.1.0.JAVA7 · eclipse/gemini.blueprint · GitHub

I was trying to replace the expanded plugin packages and restart the service `service-control --restart vsphere-ui` to verify. Is this OK?

[royling]

or, what is a quick way to validate my change in a remote virgo server?

[Tony Ganchev]

Hello royling,

Can you help us with a little bit more details about your environment.

• Can you confirm that VCSA is a preview of 6.7U1 preview and that the SDK you use (and got your local Virgo server from) is 6.7 GA? I am making these assumptions based on the is based on the spring versions you mentioned. Mismatch in the revision part of the Spring version should not be causing such an issue.
• Do you see the error you pasted in your original post after you registered your plugin into the vCSA's ExtensionManager?
• Was the plugin even deployed on the server or the error happened before your plugin started to deploy? Note: Upon further inspection looks like ClusterPropertyProvider is defined in your plugin. - please confirm.
• Did you do any patching or upgrade to the problematic vCSA?

I was trying to replace the expanded plugin packages and restart the service `service-control --restart vsphere-ui` to verify. Is this OK?

Yes, this should be OK. You can also modify/touch your bundles directly in /usr/lib/vmware-vsphere-ui/server/pickup and they'd automatically redeploy.

Best,

Tony

[royling]

• Can you confirm that VCSA is a preview of 6.7U1 preview and that the SDK you use (and got your local Virgo server from) is 6.7 GA? I am making these assumptions based on the is based on the spring versions you mentioned. Mismatch in the revision part of the Spring version should not be causing such an issue.

The SDK used in my local dev is 6.7.0.550 (downloaded from the latest vsphere client download page) and the version in the remote server is 6.7.0.200 (is this the version for 6.7U1 preview?)

• Do you see the error you pasted in your original post after you registered your plugin into the vCSA's ExtensionManager?

via MOB? I did not test it yet.

• Was the plugin even deployed on the server or the error happened before your plugin started to deploy? Note: Upon further inspection looks like ClusterPropertyProvider is defined in your plugin. - please confirm.

The error happened after the plugin was deployed. ClusterPropertyProvider is a custom property provider adapter I added in the plugin.

• Did you do any patching or upgrade to the problematic vCSA?

No, I think.

You can also modify/touch your bundles directly in /usr/lib/vmware-vsphere-ui/server/pickup and they'd automatically redeploy.

Originally I have `scope="global"` in plugin-package.xml, I can see the package is expanded into pickup folder. But later I removed it, it seems now a PAR was deployed instead. Does it mean I can not hot-deploy a non-global plugin? Which scope should I use?

[Tony Ganchev]

Both global-scoped and isolated plugins can be hot-redeployed in vCSA. With isolated plugins, you need to patch the PAR with the changed bundles so it takes one more step. Isolated scope is the preference for production deployments (we don't certify global-scoped plugins AFAIR) while global-scope is useful on your development box.

PARs are the way to guarantee that the third-party libs you ship with do not clash with the third-party libs of another plugin.

[royling]

Hi Tony,

Is it possible the issue may be caused by the mismatch of VCSA version and SDK version?

say that VCSA is 6.7U1 preview and SDK is official GA version only...

Best regards,

Roy

[Tony Ganchev]

It's not the SDK mismatch. I misread the version - 6.7.0.200 is a patch of 6.7 GA.

Spring version mismatch can't be too. Just make sure you are not packaging spring packages with your plugin.

How are you deploying your plugin to the vCSA if not using the ExtensionManager?

[royling]

Tony,

Thanks for sharing the info about global/isolated scopes.

And I'm assuming that the plugin SDK that I was using (6.7.550) in my local dev should be compatible with GA patch (6.7.200), right?

To answer your previous two questions:

> Just make sure you are not packaging spring packages with your plugin.

no spring pkgs are included.

> How are you deploying your plugin to the vCSA if not using the ExtensionManager?

We're deploying the plugin via ExtensionManager in a release environment.