Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[virgo-dev] RE: Virgo on Equinox 3.6

Hi,

 

I added a patch in enhancement request https://bugs.eclipse.org/bugs/show_bug.cgi?id=322990 that allows the execution of Virgo on Equinox 3.6 to be done only with configuration changes (adding of extensions bundle to the kernel region configuration).

 

Regards,

Hristo Iliev

 

From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Iliev, Hristo
Sent: Monday, August 16, 2010 4:22 PM
To: Virgo Project
Subject: [virgo-dev] RE: Virgo on Equinox 3.6

 

Hi,

 

The tests of virgo kernel (git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.kernel.git) passed successfully.

 

What we did was:

1.       Replace Equinox 3.5 with 3.6 in ivy cache

2.       Add “Fragment-Host= org.eclipse.osgi; extension:=framework” to osgi.extensions.equinox

3.       Comment start() method of org.eclipse.virgo.kernel.userregion.internal.equinox.EquinoxConsoleManager since it uses old/deprecated constructor of FrameworkConsole

 

Open questions:

1.       Are there really bundles which rely on loading classes from the org.eclipse.virgo.osgi.launcher and  org.eclipse.virgo.kernel.authentication? If not then the classpath can be stripped off which will significantly improve the perm usage. Also it will be clear that the change in the behavior with the child framework loader won’t break any runtime functionality.

2.       Is EquinoxConsoleManager still in use or is just dead code?

 

Regards,

Hristo Iliev

 

From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Iliev, Hristo
Sent: Tuesday, August 10, 2010 7:21 PM
To: Virgo Project
Subject: [virgo-dev] Virgo on Equinox 3.6

 

Hi,

 

We managed to start Virgo on Equinox 3.6. Here is the experience and the open points we have so far:

 

 

Running Virgo on Equinox 3.6

 

We’re using Virgo Kernel distribution: virgo-kernel-2.1.0.M02-incubation and Equinox: org.eclipse.osgi_3.6.0.v20100517.

 

 

Execution steps:

  1. Replace the Equinox implementation jar (org.eclipse.osgi_3.6.0.v20100517.jar) in <virgo_home>/lib folder
  2. The kernel region cannot start because of the following error:

[2010-08-02 15:16:31.680] startup-tracker              org.eclipse.virgo.medic.eventlog.default                         KE0003E Kernel failed to start. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.eclipse.virgo.kernel.osgi.region.RegionManager#0' defined in URL [bundleentry://31.fwk13452612/META-INF/spring/osgi-framework-context.xml]: Invocation of init method failed; nested exception is org.osgi.framework.BundleException: Failed to start bundle org.eclipse.virgo.kernel.userregion 2.1.0.M02-incubation

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

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

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

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

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

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

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

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

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

        at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)

        at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)

        at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)

        at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)

        at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)

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

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)

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

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

Caused by: org.osgi.framework.BundleException: Failed to start bundle org.eclipse.virgo.kernel.userregion 2.1.0.M02-incubation

        at org.eclipse.virgo.kernel.osgi.region.RegionManager.initialiseUserRegionBundles(RegionManager.java:320)

        at org.eclipse.virgo.kernel.osgi.region.RegionManager.createAndPublishUserRegion(RegionManager.java:152)

        at org.eclipse.virgo.kernel.osgi.region.RegionManager.start(RegionManager.java:129)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

        at java.lang.reflect.Method.invoke(Method.java:597)

        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeCustomInitMethod(AbstractAutowireCapableBeanFactory.java:1529)

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

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

        ... 17 common frames omitted

Caused by: org.osgi.framework.BundleException: Exception in org.eclipse.virgo.kernel.userregion.internal.Activator.start() of bundle org.eclipse.virgo.kernel.userregion.

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:806)

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)

        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)

        at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)

        at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:276)

        at org.eclipse.virgo.kernel.osgi.region.RegionManager.initialiseUserRegionBundles(RegionManager.java:318)

        ... 26 common frames omitted

Caused by: java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.eclipse.virgo.kernel.userregion.internal.equinox.TransformedManifestProvidingBundleFileWrapper.wrapBundleFile(Lorg/eclipse/osgi/baseadaptor/bundlefile/BundleFile;)Lorg/eclipse/osgi/baseadaptor/bundlefile/BundleFile;" the class loader (instance of org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader@42958262939402) of the current class, org/eclipse/virgo/kernel/userregion/internal/equinox/TransformedManifestProvidingBundleFileWrapper, and the class loader (instance of System@42958262899839) for interface org/eclipse/virgo/osgi/extensions/equinox/hooks/BundleFileWrapper have different Class objects for the type org/eclipse/osgi/baseadaptor/bundlefile/BundleFile used in the signature

        at org.eclipse.virgo.kernel.userregion.internal.Activator.createBundleTransformationHandler(Activator.java:138)

        at org.eclipse.virgo.kernel.userregion.internal.Activator.start(Activator.java:93)

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)

        at java.security.AccessController.doPrivileged(Native Method)

        at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)

        ... 31 common frames omitted

 

The investigation of the LinkageError showed that the org.eclipse.osgi.baseadaptor.bundlefile.BundleFile class is loaded by 2 different classloaders:

·         ApplicationLauncher because the org.eclipse.osgi is added to the java process classpath (setupClasspath script)

·         EquinoxFWClassLoader – the loader of the composite framework created for the user region

 

The loading of the org.eclipse.virgo.osgi.extensions.equinox.hooks.BundleFileWrapper which is requested from the EquinoxFWClassLoader when the user region bundle is initialized is delegated to the ApplicationLauncher loader. That’s because the class is not included in the local resources of the EquinoxFWClassLoader. Respectively the  org.eclipse.osgi.baseadaptor.bundlefile.BundleFile which the BundleFileWrapper uses is loaded again by the ApplicationLauncher.

 

The BundleFile however is present in the local resources of the EquinoxFWClassLoader and is already loaded from it on a previous step.

 

Finally when the Initialization of the BundleFileWrapper is invoked both class definitions of BundleFile collide and a LinkageError is produced.

 

  1. We did a debug session to check why this scenario had worked with equinox 3.5 and what is the difference with 3.6.

 

It appeared that there is a difference in the way the classloader of the embedded frameworks is created.

 

Previously (3.5) the child framework classloader was created with all the jars from the classpath of the parent framework’s classloader, i.e. all the virgo jars which were part of the classpath of the java process were set as resources to both kernel and user space framework. This behavior was identified as a bug (see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=296797 ) and a fix was provided in equinox 3.6.  According to the fix the child framework is created only with the org.eclipse.osgi jar and the jars of its extension bundles.

 

The org.eclipse.virgo.osgi.extensions.equinox.hooks.BundleFileWrapper is found in the lib/org.eclipse.virgo.osgi.extensions.equinox-2.1.0.M02-incubation.jar which is the jar with all the virgo specific equinox hooks. According to the equinox hooks spec the hook implementations should be packaged in an extension bundle – a fragment to the system bundle. However the org.eclipse.virgo.osgi.extensions.equinox-2.1.0.M02-incubation.jar is not defined as an extension bundle.

 

  1. We added in the manifest of the org.eclipse.virgo.osgi.extensions.equinox-2.1.0.M02-incubation.jar:

 

Fragment-Host: org.eclipse.osgi; extension:=framework

 

Thus the org.eclipse.virgo.osgi.extensions.equinox-2.1.0.M02-incubation.jar is recognized as a framework extension and added along with the org.eclipse.osgi jar in the classloader of the user region framework. The startup of the Virgo server is successful – the states of the bundles in both user and kernel regions are the same as the bundle states when Virgo runs with equinox 3.5.

 

Open points:

The Virgo server is started with classpath containing all the jars found in its lib folder (over 40 jars). Only 3 of these jars can be actually used by the bundles inside the framework because their packages are described in org.osgi.framework.bootdelegation property (java6-server.profile):

org.osgi.framework.bootdelegation = \

org.eclipse.virgo.osgi.extensions.*,\

         org.eclipse.virgo.osgi.launcher.*,\

         org.eclipse.virgo.kernel.authentication,\  

We successfully started the Virgo server with only 3 jars in the classpath:

-classpath E:\develop\equinox\Virgo\virgo_3.6\lib\org.eclipse.osgi_3.6.0.v20100517.jar;E:\develop\equinox\Virgo\virgo_3.6\lib\org.eclipse.virgo.osgi.launcher-2.1.0.M02-incubation.jar;E:\develop\equinox\Virgo\virgo_3.6\lib\org.eclipse.virgo.osgi.extensions.equinox-2.1.0.M02-incubation.jar

 

 

  1. Are there really bundles which rely on loading classes from the org.eclipse.virgo.osgi.launcher and  org.eclipse.virgo.kernel.authentication? If not then the classpath can be stripped off which will significantly improve the perm usage. Also it will be clear that the change in the behavior with the child framework loader won’t break any runtime functionality.

 

  1. How can we test that all Virgo functionality works without actually integrating the changes in the build? I guess the easiest way would be to modify some of the test project configurations (integration tests for example). Are there any other options?

 

 

Regards,

Hristo Iliev

 

 

 


Back to the top