Plugin doesn't show up after successfull registration - BeanCreationException

[manojmpillai]

I have a setup as below

vcenter server and client 5.5, a plugin developed on top of 5.5 client. When I register the plugin I don't see any problem and it ends successfully. But the plugin does not show up on the web client.

This happened on an installed base and right now we don't have the logs handy. Have captured the snap of the exception trace and attached along with. 

Some important points

1. We do bundle vim25.jar with our plugin and copy it to the destination along with our jars.

2. We observed that another plugin was installed prior to registering ours.

We suspect some package conflicts or so based on the above two points...Any help , pointers/suggestions will be deeply appreciated.

Regards

Manoj

[manojmpillai]

Please if anyone could respond to this post. we are stuck and trying to see what could be a cause for the package conflict.

[laurentsd]

The full virgo log is necessary to understand what was deployed since the server started.

[manojmpillai]

Thanks for having a quick look Laurent.

I will get you the complete logs shortly. But in general if there is more than one plugin getting registered with a web client and they have some package comflict, here we suspect vijava and vim25, what could be the strategy.

To Summarise so far (pending complete logs from my side)

We use the following dependencies in our plugin...

commons-logging-1.1.1

data-services-1.0.0

flex-messaging-common

flex-messaging-core

spring-flex-core-1.5.2

vim25

vsphere-client-lib

The second party uses the below dependencies

commons-logging-1.1.3

commons-lang3-3.1

com.springsource.org.dom4j-1.6.1

libthrift-0.9.1

thrift-1.0

vijava-eam-5.5.2

guava-17.0

**If our plugin is installed/registered first followed by the second party plugin, everything is absolutely fine. The problem is when the order is vice versa.**

We suspect vim25 and vijava as conflicting packages. Do you think so? If so do you think the attached exception is a result of the conflict? If so what are your inputs in resolving this out?

Thanks

Manoj

[Peter_Ivanov]

Please look at this thread:

vim25.jar present but receiving ClassNotFoundException

You are experiencing the same "vijava" problem

[Peter_Ivanov]

We suspect vim25 and vijava as conflicting packages. Do you think so? If so do you think the attached exception is a result of the conflict? If so what are your inputs in resolving this out?

Your suspicion is absolutely correct. If you look at the vijava MANIFEST.MF file, you will see that it exports com.vmware.vim25 package - the same as the vim25.jar.

The correct way of fixing this is to specify version when Export/Import-Package. Please note that you should specify the version like this:

version="[6.0.0-6.0.0]" - correct; defines a strict range

version="6.0.0" - wrong. This means 1.0.0 and above

http://www.eclipse.org/virgo/documentation/virgo-documentation-3.6.0.M01/docs/virgo-user-guide/html/...

Unfortunately vim25.jar does not specify export package version. This is fixed in 6.0 Update 2 release that is coming out shortly.

You can also patch it yourself. Please let me know if you need details on how to do that.

Without touching the vim25.jar you could try using Require-Bundle. It should solve your problem:

Require-Bundle: com.vmware.wsvim25;bundle-version=1.0.0

[manojmpillai]

Thanks Peter. We will in-corporate the changes you mentioned and try it out. Will let you know the results before closing the discussion.

Thanks for your support and time.

[manojmpillai]

Hello Peter,

At least the solution was approved by our inhouse verification team and its under user acceptance..

But meanwhile we noticed a related issue for which I have created a new thread.

https://developercenter.vmware.com/forums?id=4974#532484|3233035

We can close this one. Please have a look at the new one.

Thanks for your support.

[manojmu]

Laurent & Peter,

We had delivered a fix for this problem by including version number 1.0.0 in our plugin manifest viz.

com.vmware.vim25;version="[1.0.0,1.0.0]". No failure ereports have been notified thereafter from that particular field. But today we received another issue which is little more tricky and it is not loading the required vim25 bundle. While the issue in this thread talked about loading a wrong bundle.

This time its an Appliance vCenter and I am attaching the log file here for your reference. As you see it tried to pick the jar from the pickup directory of the virgo server and I see that the jar over there is hosted by some another party. More importantly it does not expose a version while exporting.

Idealy I believe we have to improve our code to have something like below

com.vmware.vim25;version="[1.0.0,1.0.0)" which will take care of 1.0.0 and higher.

But here the question is why it is not loading the jar packaged by us in the bundle itself. Why is it only looking at pickup directory of the server.

Please help. Customer has multiple plugins installed and unfortunately our plugin is the one having this issue.

Thanks

Manoj

[manojmu]

Latest update from analysis of logs

The problem is very clear now. There is another plugin xyz which packages a version on vim25.jar that exposes no version in the MANIFEST. when this xyz plugin is deployed the jar is copied to the pickup directory of the server. Now when our plugin(which packages a vim25.jar too and with the version in MANIFEST) gets loaded it fails saying

"An Import-Package could not be resolved. Resolver error data <Import-Package: com.vmware.vim25; version="[1.0.0,1.0.0]">. Caused by missing constraint in bundle <com.cisco.ucs.vcplugin.service_1.2.2>
             constraint: <Import-Package: com.vmware.vim25; version="[1.0.0,1.0.0]">"

We cannot get away with the mention of version in our import because of the problem discussed in this thread initially. So there has to be another solution for this which would work in both cases.

Nutshell...

Case 1 : A different bundle(VIJAVA) that exposes the package "com.vmware.vim25" without version in MANIFEST

Solution : We mentioned version in the import statement of our plugin MANIFEST.

Case 2 : Same bundle(vim25.jar) that exposes the package "com.vmware.vim25" without version in MANIFEST coming from another plugin is loaded first leaving the one shipped by us ignored leading to our plugin failure.

Solution : We need to find the best solution using the MANIFEST entities like import OR/AND Required Bundle OR/AND Bundle-classpath etc so that both these situations are handled and in fact other such conflicts too.

Please help us in finding the right solution.

[laurentsd]

Thanks for the update. Have you tried nesting a copy of vim25.jar inside your .jar bundle?

i.e. you add Bundle-ClassPath: .,vim25.jar  to your MANIFEST.MF, and you include vim25.jar at the root of your jar file.

[manojmu]

Thanks for the reply Laurent. I just trued that on my development virgo. First it cribbed about my other dependencies . I added them too. So I had 3 jars in my root folder and mentioned them in Bundle-ClassPath. Now it gives me the following trace.

[2016-09-02 12:39:34.821] [ERROR] region-dm-13                  <AG0000E> Application context creation failure for bundle 'com.cisco.ucs.vcplugin.service' version '0.0.0'. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ObjectNavigatorVSphereDataAdapter': Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ObjectNavigatorVSphereDataAdapterImpl' defined in URL [bundleentry://279.fwk5949134/META-INF/spring/bundle-context.xml]: Instantiation of bean failed; nested exception is java.lang.ExceptionInInitializerError

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

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

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

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

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

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

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

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

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

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

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

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

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

  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)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

  at java.lang.Thread.run(Unknown Source)

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ObjectNavigatorVSphereDataAdapterImpl' defined in URL [bundleentry://279.fwk5949134/META-INF/spring/bundle-context.xml]: Instantiation of bean failed; nested exception is java.lang.ExceptionInInitializerError

  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:288)

  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1035)

  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:939)

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

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

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

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

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

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

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

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

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

  ... 17 common frames omitted

Caused by: java.lang.ExceptionInInitializerError: null

  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

  at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)

  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

  at java.lang.reflect.Constructor.newInstance(Unknown Source)

  at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:147)

  at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:110)

  at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:280)

  ... 28 common frames omitted

Caused by: com.sun.xml.internal.ws.model.RuntimeModelerException: A WebService annotation is not present on class: com.vmware.vim25.VimPortType

  at com.sun.xml.internal.ws.model.RuntimeModeler.buildRuntimeModel(Unknown Source)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.createSEIPortInfo(Unknown Source)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.addSEI(Unknown Source)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)

  at com.sun.xml.internal.ws.client.WSServiceDelegate.getPort(Unknown Source)

  at javax.xml.ws.Service.getPort(Unknown Source)

  at com.vmware.vim25.VimService.getVimPort(Unknown Source)

  at com.cisco.ucs.vcplugin.service.ObjectNavigatorVSphereDataAdapter.initializeVimPort(ObjectNavigatorVSphereDataAdapter.java:205)

  at com.cisco.ucs.vcplugin.service.ObjectNavigatorVSphereDataAdapter.<clinit>(ObjectNavigatorVSphereDataAdapter.java:197)

  ... 35 common frames omitted

Hope we are not yet there. Any further guesses / suggestions please?

[laurentsd]

Embedding libraries like vim25.jar inside your own bundle is a proven way to get things working (see Best Practices for Extending the Service Layer)  So the errors you are experiencing must come from somewhere else or you didn't embed the libraries properly.  It is impossible for us to know what is wrong without a reproducible test case.  The best way to get help would be to modify an existing SDK sample with just enough code to reproduce your problem and then send us the delta for that sample.

[manojmu]

Thank you laurent. I understand what you say. I am attaching a zip file. The contents are as follows

1. globalview-service

    Changes

    a. Manifest file

    b. lib/vim25.jar - this has a version exposed for com.vmware.vim25 as "1.0.0"

    c. com.vmware.samples.globalview.GlobalServiceImpl - added some code to have a dependency on vim25 classes.

    d. build-java.xml - to have compile time dependency with vim25.jar and also to pack it under the root folder during jar creation.

2. vim25.jar in 3 variants. Intention is that the plugin should work with any of these depending on which ever is included in the Bundle-Classpath.

I am able to reproduce the last error trace I have pasted here with this plugin getting deployed in my development virgo server. I don't have anything in my pickup folder.

Please build the sample using build-java.xml, deploy and check if you can reproduce this at your end and suggest a possible solution for us if possible.

Regards

Manoj

[manojmu]

Laurent, Any updates on this please.

Thanks

Manoj

[laurentsd]

Your request is not simple and this is a free forum.  Our response time typically varies based on the load of developers who have a full time job besides helping users.  Thanks for being patient.

[manojmu]

I understand laurent. Sorry for the previous reminder which was very quick.

Please consider this as my first gentle reminder. Please let us know if there is any update on this.

[laurentsd]

I was able to reproduce your problem and found the solution.

When you nest vim25.jar inside your own bundle you also need to import the packages that vim25.jar was importing (see its MANIFEST.MF).  I added the 2 blue lines below to globalview-service.jar and its deployment worked.  We'll have to make this clearer in our doc!

Import-Package: org.apache.commons.logging,org.apache.commons.lang,org

.osgi.framework,org.springframework.flex.core,flex.messaging,

javax.jws,javax.xml.bind,javax.xml.bind.annotation,

javax.xml.datatype,javax.xml.namespace,javax.xml.ws

Export-Package: com.vmware.samples.globalview

Bundle-ClassPath: .,vim25.jar

[manojmu]

Thanks much laurent.

This seems to work for the sample plugin and I will integrate this with our core plugin and check with the customer if it fixes the issue.

So with this fix, I would like to conclude few points and get your Yes/No on each of them please

1. Both the issues discussed in this thread and for that matter any package conflict w.r.t vim25.jar is resolved with the fix.

2. We don't need to mention com.vmware.vim25;version="[1.0.0,6.5.0]" which was suggested for the first problem in this thread.

3. We just have to add Bundle-ClassPath entry and also import the packages important by vim25.jar

4. With this any furture changes in vim25.jar we just have to download , use and package it with the plugin without any changes in the Manifest.

Please put in your thoughts on the above while I get to know from the customer.

Regards

Manoj M

[laurentsd]

> 1. Both the issues discussed in this thread and for that matter any package conflict w.r.t vim25.jar is resolved with the fix.

> 2. We don't need to mention com.vmware.vim25;version="[1.0.0,6.5.0]" which was suggested for the first problem in this thread.

Either you include vim25.jar inside your own service jar file and there is no version to mention since it is right there, or you use vim25.jar as an external library and your own MANIFEST should contains Import-Package: com.vmware.vim25.jar;version="6.0.2" with the proper version from the vim25.jar MANIFEST.

> 3. We just have to add Bundle-ClassPath entry and also import the packages imported by vim25.jar

To avoid potential conflicts like the ones mentioned in this thread, yes, the recommended way is to include vim25.jar in your own service jar.  In this case you also need to import packages as I described in my previous reply to solve the error "A WebService annotation is not present on class: com.vmware.vim25.VimPortType".  If that error doesn't happen because the plugin code is not using VimPortType it may be that importing those additional packages is not required.

> 4. With this any future changes in vim25.jar we just have to download , use and package it with the plugin without any changes in the Manifest.

You only need to update vim25.jar when you are using new vSphere Management SDK APIs.