Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » XMLBeans dependency(Deploy WAR)
XMLBeans dependency [message #633172] Fri, 15 October 2010 10:45 Go to next message
Marco Plebani is currently offline 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
Re: XMLBeans dependency [message #633197 is a reply to message #633172] Fri, 15 October 2010 11:46 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: XMLBeans dependency [message #633598 is a reply to message #633197] Mon, 18 October 2010 10:05 Go to previous messageGo to next message
Marco Plebani is currently offline 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
Re: XMLBeans dependency [message #633637 is a reply to message #633172] Mon, 18 October 2010 11:38 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: XMLBeans dependency [message #633706 is a reply to message #633172] Mon, 18 October 2010 21:44 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: XMLBeans dependency [message #633746 is a reply to message #633172] Tue, 19 October 2010 04:39 Go to previous messageGo to next message
Marco Plebani is currently offline 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
Re: XMLBeans dependency [message #633747 is a reply to message #633746] Tue, 19 October 2010 04:52 Go to previous messageGo to next message
Glyn Normington is currently offline 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
Re: XMLBeans dependency [message #633752 is a reply to message #633747] Tue, 19 October 2010 05:37 Go to previous messageGo to next message
Marco Plebani is currently offline 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
Re: XMLBeans dependency [message #633761 is a reply to message #633752] Tue, 19 October 2010 06:07 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: XMLBeans dependency [message #633764 is a reply to message #633761] Tue, 19 October 2010 06:20 Go to previous messageGo to next message
Marco Plebani is currently offline 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
Re: XMLBeans dependency [message #633766 is a reply to message #633764] Tue, 19 October 2010 06:43 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: XMLBeans dependency [message #634037 is a reply to message #633766] Wed, 20 October 2010 06:54 Go to previous message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Although it doesn't help your scenario much, I have recorded the alternative way of deploying the hosted repository application under bug 328229.
Previous Topic:why do I need to press Ctrl-F5 to view new posts?
Next Topic:Virgo Release Candidate
Goto Forum:
  


Current Time: Mon Jul 28 10:34:35 EDT 2014

Powered by FUDForum. Page generated in 0.04242 seconds