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
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.
- Replace
the Equinox implementation jar (org.eclipse.osgi_3.6.0.v20100517.jar) in
<virgo_home>/lib folder
- 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.
- 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.
- 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.
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
- 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.
- 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?