Eclipse Community Forums: Virgo » XMLBeans dependency

Help

Home

Home » Eclipse Projects » Virgo » XMLBeans dependency(Deploy WAR)

Show: Today's Messages :: Show Polls :: Message Navigator

XMLBeans dependency [message #633172]

Fri, 15 October 2010 14:45

Marco Plebani

Messages: 9
Registered: October 2010

Junior Member

Hi,
the context is the following.

I'm trying to install an existing WAR in virgo.
I got a remote virgo repository linked my my local virgo server. I put in the hosted folder the libraries required by my WAR. The WAR is in the local repository/usr folder (but this is not important).

In the manifest.mf file of the WAR there is the following dependencies, besides other declared dependecies:

Import-Bundle: com.springsource.org.apache.xmlbeans;version="[2.4.0,2.4.0] "

Now. If the com.springsource.org.apache.xmlbeans is installed in the local repository/usr the WAR deployment phase goes well. Otherwise, if the jar file is in the remote repository I got a strange error:


[2010-10-15 16:40:18.069] start-signalling-1           org.springframework.web.context.ContextLoader                     Context initialization failed java.lang.NoClassDefFoundError: org/apache/xmlbeans/XmlException
	at java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
	at java.lang.Class.getDeclaredConstructors(Class.java:1836)
	at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.determineCandidateConstructors(AutowiredAnnotationBeanPostProcessor.java:225)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.determineConstructorsFromBeanPostProcessors(AbstractAutowireCapableBeanFactory.java:909)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:882)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:479)
	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.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:416)
	at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:261)
	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:192)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4182)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4682)
	at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
	at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
	at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:546)
	at org.eclipse.gemini.web.tomcat.internal.TomcatServletContainer.startWebApplication(TomcatServletContainer.java:120)
	at org.eclipse.gemini.web.internal.StandardWebApplication.start(StandardWebApplication.java:90)
	at org.eclipse.virgo.web.core.internal.WebBundleLifecycleListener.onStarted(WebBundleLifecycleListener.java:120)
	at org.eclipse.virgo.kernel.install.artifact.internal.ArtifactStateMonitor.onStarted(ArtifactStateMonitor.java:205)
	at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.asyncStartSucceeded(AbstractInstallArtifact.java:273)
	at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact.access$0(AbstractInstallArtifact.java:270)
	at org.eclipse.virgo.kernel.install.artifact.internal.AbstractInstallArtifact$StateMonitorSignal.signalSuccessfulCompletion(AbstractInstallArtifact.java:223)
	at org.eclipse.virgo.kernel.core.internal.BundleStartTracker$1.run(BundleStartTracker.java:140)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:637)
Caused by: org.eclipse.virgo.kernel.osgi.framework.ExtendedClassNotFoundException: org.apache.xmlbeans.XmlException in KernelBundleClassLoader: [bundle=org.springframework.oxm_3.0.0.RELEASE]
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:139)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
	... 34 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.apache.xmlbeans.XmlException
	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:506)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422)
	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:135)
	... 35 common frames omitted

Analyzing the virgo admin application I noticed that, after the installation, some of the required bundle is resolved and installed but XMLBeans is not installed as a bundle.

I also noticed, in an another test case, that if I install the jar inside the repository/usr folder before the startup of the server, when the server is on the admin application reports me that the jar is installed as a JAR.

Can anyone explain me what's the problem? Is the order of the Import-Bundle so important?

Thanks
-- Marco

Report message to a moderator

Re: XMLBeans dependency [message #633197 is a reply to message #633172]

Fri, 15 October 2010 15:46

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

This sounds like a bug or possibly a setup error. Please can you raise a bug.

If you have the time to create a minimal testcase to reproduce the problem and attach it to the bug, that would be extremely helpful.

Report message to a moderator

Re: XMLBeans dependency [message #633598 is a reply to message #633197]

Mon, 18 October 2010 14:05

Marco Plebani

Messages: 9
Registered: October 2010

Junior Member

It's not so easy to create a simple test case. My application is too complex and there is a problem related to license.

As soon as the test case is created I will notify "you" in Bugzilla.

Thanks a lot.
-- Marco

Report message to a moderator

Re: XMLBeans dependency [message #633637 is a reply to message #633172]

Mon, 18 October 2010 15:38

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Re-reading the scenario, I realised what the problem is.

The hosted repository application, deployed in the pickup directory of Virgo, provides access to the remote repository but only after it has successfully initialised.

So it seems parts of your application and the "oxm" bundle are resolved before the hosted repository application has finished initialising - an asynchronous operation because it uses Spring DM.

This is a restriction because of the hosted repository application being deployed along with other applications.

So I would recommend avoiding dependencies from local bundles needing to be resolved from remote bundles.

If you would like us to consider lifting this restriction, please raise an enhancement bugzilla and we can consider it in due course.

I hope that at least helps explain the situation and shows a way forward.

Report message to a moderator

Re: XMLBeans dependency [message #633706 is a reply to message #633172]

Tue, 19 October 2010 01:44

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Another workaround is to change the startup order of the Virgo user region by making the hosted repository application one of the artefacts initially deployed in the user region instead of deploying it from pickup. This will ensure that the hosted repository application starts ahead of applications deployed from pickup or via the admin console.

It's very easy to make this change. Simply move the app from pickup to repository/ext, e.g.

mv pickup/org.eclipse.virgo.apps.repository-2.1.0.M06-incubation.par repository/ext/.

and then edit config/org.eclipse.virgo.kernel.userregion.properties so the initialArtifacts property is set as follows (but on a single line):

initialArtifacts=repository:plan/org.eclipse.virgo.kernel.userregion.springdm, repository:plan/org.eclipse.virgo.web, repository:par/org.eclipse.virgo.apps.repository

and cold start Virgo.

Report message to a moderator

Re: XMLBeans dependency [message #633746 is a reply to message #633172]

Tue, 19 October 2010 08:39

Marco Plebani

Messages: 9
Registered: October 2010

Junior Member

Hi Glyn,
I followed your instruction, but the result is the same.

Now:
1) the XMLBeans JAR is in the hosted repository.
2) org.eclipse.virgo.apps.repository-2.1.0.M06-incubation.par is in the ext repository
3) the initialArtifacts is set as you indicated.

The error is the same:
- Context initialization failed java.lang.NoClassDefFoundError: org/apache/xmlbeans/XmlException

BUT, differently from the initial test XMLBean is installed as a JAR.

Best regards.
-- Marco

Report message to a moderator

Re: XMLBeans dependency [message #633747 is a reply to message #633746]

Tue, 19 October 2010 08:52

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Hi Marco

Thanks for your patience. I do believe we are making progress, albeit slowly. Smile

It seems that the "oxm" bundle is still being resolved relatively early and the optional import is being dropped because the XMLBeans JAR is not found at that time (because the hosted repository application is not yet running).

If you use the admin console and explore the OSGi state, you'll be able to see which bundles are wiring to the "oxm" bundle. I'm guessing some of these are fairly basic Spring bundles and if so, this would explain why "oxm" is resolved early. The fix in that case is to put the XMLBeans JAR in repository/usr.

Regards,
Glyn

Report message to a moderator

Re: XMLBeans dependency [message #633752 is a reply to message #633747]

Tue, 19 October 2010 09:37

Marco Plebani

Messages: 9
Registered: October 2010

Junior Member

Hi Glyn,
Thank you for the support. Now, I'm not in a hurry with my project Smile

Now, I'm using the XMLBean jar in the usr repository.

I don't know if the following information is useful to you.

First of all I found two different version of OXM.
- 3.0.0 included in the virgo distro.
- 1.5.9.A used by my application.

Note that my application was developed using Spring 2.5. In the first experiments I had tried to include Spring 2.5 in the bundle dependency with any positive result; the problem was raised up by OXM dependency. Now the project uses Spring 3.0; fortunately I got no problem.

This is which bundles are wiring to the "oxm" bundle:
- Version 1.5.9.A
org.apache.xmlbeans [2.4.0, 3)
some spring inclusions
some apache and 3-part libraries.

- Version 3.0.0
org.apache.xmlbeans [2.2.0, 3)

Do you need other information?

Thanks
-- Marco

Report message to a moderator

Re: XMLBeans dependency [message #633761 is a reply to message #633752]

Tue, 19 October 2010 10:07

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

No, that's quite sufficient thanks. Please note that we strongly recommend not using more than one version of Spring (in the user region - the kernel can run a different version quite happily) because this can cause lots of issues with the Spring DM extender.

Report message to a moderator

Re: XMLBeans dependency [message #633764 is a reply to message #633761]

Tue, 19 October 2010 10:20

Marco Plebani

Messages: 9
Registered: October 2010

Junior Member

Glyn,
I exploit this thread for one question about dependency.

With the WAR application running in Virgo, we are trying to move the WAR application to the Share Services WAR.

The modularized application that we have in mind is composed by:
- a WAR web application
- a set of bundle; each bundle expose a set of service. The WAR application routes the request to the necessary bundle using Spring Integration.

Each bundle uses two different kind of libraries:
- OSGi-ed libraries
- non OSGi-ed libraries, provided by 3-part.

We obviously have no problem with the OSGi library. On the other hand we cannot modify the second type of library so we cannot insert any MANIFEST file.

There is a way to declare the dependency in a bundle (not the WAR) this kind of noOSGi-library?

Thanks a lot for your support.
-- Marco

Report message to a moderator

Re: XMLBeans dependency [message #633766 is a reply to message #633764]

Tue, 19 October 2010 10:43

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

The usual trick for 3rd party JARs that you can't crack open is to include them in the bundle classpath of a bundle.

If only one bundle needs to depend on the 3rd party JAR, it is possible to add the 3rd party JAR to that bundle's bundle classpath.

However, a more general solution is to create a bundle which contains just the 3rd party JAR on the bundle classpath and simply exports all the packages of the 3rd party JAR and imports any dependencies, very much like the manifest you would have liked to have put in the 3rd party JAR if you were able to crack it open.

Tools like bundlor can help with generating such manifests.

Hope that helps.

Report message to a moderator