Eclipse Community Forums: Virgo » Sudden failure of dependency resolution

Help

Home

Home » Eclipse Projects » Virgo » Sudden failure of dependency resolution

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

Sudden failure of dependency resolution [message #634848]

Sun, 24 October 2010 15:22

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

HI I have a plan with dependencies to bundles that lie in repository/usr. It used to deploy fine until an hour ago. Now it fails with a whole lot of dependency errors (takes two minutes to calculate) like

[2010-10-24 16:50:01.318]  TCP Connection(2)-127.0.0.1 <DE0002E> Installation of plan 'eiswind-publishing-server.plan' version '1.7.0' failed. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'eiswind-publishing-server.plan-1.7-de.eiswind.mango.domain' at version '1.7.0.20101020': Cannot resolve: eiswind-publishing-server.plan-1.7-de.eiswind.mango.domain
    Unsatisfied leaf constraints:
        Bundle: eiswind-publishing-server.plan-1.7-de.eiswind.mango.server.core_1.7.0 - Import-Package: org.codehaus.groovy.runtime.dgmimpl; version="0.0.0"
            Did you mean: 'org.aspectj.runtime.internal'?
        Bundle: eiswind-publishing-server.plan-1.7-de.eiswind.mango.server.core_1.7.0 - Import-Package: org.apache.jackrabbit.core.query; version="0.0.0"
            Did you mean: 'org.apache.jk.core'?

... a million other lines

I tried to clear stage and work directory, but it still fails. I dont know what I did to make it break.

In the dump I can see that virgo recognizes my bundles in usr.. I depend on the bundles using import-bundle so I completely don't get it.

There must be something broken I guess, as it did work all the time.

Any hints would be greatly appreciated.
Regards Thomas

Report message to a moderator

Re: Sudden failure of dependency resolution [message #634933 is a reply to message #634848]

Mon, 25 October 2010 07:44

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

I assume you tried starting using -clean, but please confirm.

Did you change the content of any repository?

I would focus in on a particular unresolved package dependency such as org.codehaus.groovy.runtime.dgmimpl and see if that has gone AWOL. When the resolution error occurs, Virgo dumps the side state it is working with to disk. You can use the admin console OSGi state explorer to examine this state dump. Look for the Groovy runtime bundle and check that it is resolved and is exporting the dgmimpl package.

Report message to a moderator

Re: Sudden failure of dependency resolution [message #634936 is a reply to message #634933]

Mon, 25 October 2010 07:54

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

Hi Glyn, thanks for the quick reply. And yes I started with -clean option (at least in the virgo tools it is set, does this work ? )

I didn't change anything (I would always tell that Smile

). The packages are definitively exported, I guess virgo wouldn't look for them otherwise as I use "Import-Bundle" for groovy and the other bundles. I think it uses the export to expand the import-bundle on deployment, right ?

How can I see wether the bundle is resolved in the dump ? I only found that its recognised in the usr repo as its in the xml from the dump.

Report message to a moderator

Re: Sudden failure of dependency resolution [message #634945 is a reply to message #634936]

Mon, 25 October 2010 08:09

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Please paste the event log messages relating to the resolution failure. I'd like to see whether a state dump was generated.

Report message to a moderator

Re: Sudden failure of dependency resolution [message #634947 is a reply to message #634945]

Mon, 25 October 2010 08:15

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

I'll provide it tonight. Have to get daytime job done first ...

Report message to a moderator

Re: Sudden failure of dependency resolution [message #634954 is a reply to message #634947]

Mon, 25 October 2010 08:23

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Ok. In that case, try using the admin console OSGi State tab as described above. See the user guide for more details. (The OSGi state dump is binary, so you can't view it with an editor.)

[Updated on: Mon, 25 October 2010 08:37]

Report message to a moderator

Re: Sudden failure of dependency resolution [message #634986 is a reply to message #634954]

Mon, 25 October 2010 10:45

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

I do not get a dump. Found a minute in my break.
I do not see my bundles from usr in the osgi state.
Theres nothing new in the event log, will attach it

Attachment: eventlog.log
(Size: 1.61MB, Downloaded 288 times)

Report message to a moderator

Re: Sudden failure of dependency resolution [message #635032 is a reply to message #634986]

Mon, 25 October 2010 13:24

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

I'm surprised you don't get a dump as that's normal for resolution failures and the DE0002E message is normally issued straight after the dump generated message ME0003I.

If you'd like to diagnose why you're not getting a dump, please debug org.eclipse.virgo.kernel.userregion.internal.quasi.Dependenc yCalculator.calculateDependencies

            doSatisfyConstraints(bundles, state);

            StateDelta delta = state.resolve(bundles);

            for (BundleDescription description : bundles) {
                if (!description.isResolved()) {
                    generateDump(state);

and see whether generateDump is called and, if so, why it doesn't work.

However, I'm not surprised you don't see any bundles added to OSGi because we do this dependency calculation in a "side" state to avoid polluting the OSGi framework (actually the user region). It is this side state which should be dumped to disk and which you can then, hopefully fruitfully, explore using the admin console to determine the real source of the error.

If you do find the time to attach a debugger, the doSatisfyConstraints method above should pull in the dependencies from repository/usr into the side state, so you'll be able to see whether you are getting the set of dependencies you expect.

Hope that's some help!

Report message to a moderator

Re: Sudden failure of dependency resolution [message #635125 is a reply to message #635032]

Mon, 25 October 2010 16:57

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

HI Glyn, don't have time to debug until the weekend. But I tried the following: I removed all Import-Bundle and Import-Library from the manifest. Now its says something even more strange to me:

[2010-10-25 18:48:55.265] TCP Connection(35)-127.0.0.1 <DE0003E> Install failed for plan 'eiswind-publishing-server.plan' version '1.7.0'. 
[2010-10-25 18:48:55.272] TCP Connection(35)-127.0.0.1 <DE0500E> Unable to install application from URI 'file:/C:/virgo-web-server-2.1.0.RC1-incubation/stage/server.plan'. Cannot satisfy constraints for bundle 'eiswind-publishing-server.plan-1.7-de.eiswind.mango.server.core' version '1.7.0'. Cannot resolve: eiswind-publishing-server.plan-1.7-de.eiswind.mango.server.core
. org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'eiswind-publishing-server.plan-1.7-de.eiswind.mango.server.core' at version '1.7.0': Cannot resolve: eiswind-publishing-server.plan-1.7-de.eiswind.mango.server.core

	at org.eclipse.virgo.kernel.install.pipeline.stage.resolve.internal.QuasiResolveStage.process(QuasiResolveStage.java:45)
	at org.eclipse.virgo.kernel.install.pipeline.internal.StandardPipeline.doProcessTree(StandardPipeline.java:62)

which I do not understand at all. I'll show you my Manifest

Manifest-Version: 1.0
Bundle-Vendor: Eiswind Software
Bundle-Name: Server Core
Bundle-SymbolicName: de.eiswind.mango.server.core
Bundle-Version: 1.7.0
Bundle-ManifestVersion: 2
Import-Package: javax.persistence;version="[2.0.0,2.0.0]",
 javax.persistence.criteria;version="[2.0.0,2.0.0]",
 javax.persistence.metamodel;version="[2.0.0,2.0.0]",
 javax.persistence.spi;version="[2.0.0,2.0.0]",
 javax.sql,
 org.apache.log4j;version="[1.2.16,1.2.16]",
 org.aspectj.lang;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.lang.annotation;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.lang.internal.lang;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.lang.reflect;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.runtime;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.runtime.internal;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.runtime.internal.cflowstack;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.runtime.reflect;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.ast;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.bcel;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.bcel.asm;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.internal.tools;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.loadtime;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.loadtime.definition;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.ltw;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.model;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.patterns;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.reflect;version="[1.6.5,1.6.6.RELEASE]",
 org.aspectj.weaver.tools;version="[1.6.5,1.6.6.RELEASE]",
 org.springframework.osgi.compendium.cm;version="[1.2.1,1.2.1]"
Export-Package:  de.eiswind.mango.server.foreignkeys,
 de.eiswind.mango.server.hibernate,
 de.eiswind.mango.server.jbpm,
 de.eiswind.mango.server.jobs,
 de.eiswind.mango.server.messages,
 de.eiswind.mango.server.setup,
 de.eiswind.mango.server.xmpp,
 de.eiswind.mango.server.xmpp.locking,
 de.eiswind.paris.server.aspects,
 de.eiswind.paris.server.core,
 de.eiswind.paris.server.dao,
 de.eiswind.paris.server.factsheet,
 de.eiswind.paris.server.services.catalogue,
 de.eiswind.paris.server.services.impl,
 de.eiswind.paris.server.services.mailinglist

Any idea on this? I get the same when I try to deploy the bundle alone (without the rest of the plan)

btw I started on a clean rc1 installation with spring 3.0.4
and javax.persistence 2.0.0 added an hour ago, so it must be something wrong with my bundle. I guess its not virgo' s fault then.

Report message to a moderator

Re: Sudden failure of dependency resolution [message #635550 is a reply to message #635125]

Wed, 27 October 2010 10:22

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

Can anyone help me out with this ? I'm feeeling quite desperate.

Report message to a moderator

Re: Sudden failure of dependency resolution [message #635556 is a reply to message #635125]

Wed, 27 October 2010 10:51

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

I can't see any obvious problem. Virgo should be reporting a more specific reason for not being able to resolve the bundle, but Virgo is at the mercy of the Equinox resolver and sometimes the resolution problem, which is NP complete, is just too hard.

I can only suggest doing a binary chop on the package imports to find out which are to blame. I would start by removing the aspectj ones (because of runtime/weaver distinction and the fact that aspectj is imported from the kernel into the user region which has caused other issues, in particular Import-Bundle isn't very helpful) and see if that allows the bundle to resolve.

If you don't fancy the binary chop, you could try installing the bundle directly in the Equinox console (using install, not vsh install) and then use the diag command and see if you get any specific resolution diagnostics.

Report message to a moderator

Re: Sudden failure of dependency resolution [message #635687 is a reply to message #635550]

Wed, 27 October 2010 17:46

Dmitry Sklyut

Messages: 279
Registered: January 2010

Senior Member

Do you have all of the required dependencies in the repository chain?

Have you tried deploying individual bundles from pickup just to see if they resolve?

This might be boiling down to "faulted" in bundle not getting resolved prior to your plan starting. Need to examine each individual manifest for the bundles in the plan to see what they use.

Are you using bundlor or how do you generate manifests?

I am leaning towards something is not imported or not "faulted" in right now as I see following log entries:

Bundle: eiswind-publishing-server.plan-1.7-de.eiswind.mango.domain_1.7.0.20101020 - Import-Package: org.hibernate.search.cfg; version="0.0.0"
            Did you mean: 'org.aspectj.weaver.bcel'?

Report message to a moderator

Re: Sudden failure of dependency resolution [message #636278 is a reply to message #635687]

Sat, 30 October 2010 10:21

Thomas Kratz

Messages: 165
Registered: July 2009

Senior Member

I finally managed to track this down. I had an error in on of the bundles that needs to be faulted in from usr. I had a duplicate import package in the manifest which lead to the following error when I tried to deploy the bundle standalone:

[2010-10-30 11:54:06.012]  TCP Connection(2)-127.0.0.1 <DE0002E> Installation of plan 'eiswind-publishing-server.plan' version '1.7.0' failed. org.eclipse.virgo.kernel.serviceability.Assert$FatalAssertionException: input packageImports must not contain duplicate items
	at org.eclipse.virgo.kernel.serviceability.Assert.isNull(Assert.java:103)

Maybe this could be reported anyway when faulted in ?

Report message to a moderator

Re: Sudden failure of dependency resolution [message #636630 is a reply to message #636278]

Tue, 02 November 2010 09:43

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Glad you got to the root cause! However, I agree that the diagnostics were not particularly helpful in this case. Please would you raise a bug and attach the full stack trace of the FatalAssertionException? If you could also afford the time to package up a simple test that reproduces the problem, that would be extremely helpful.

Report message to a moderator

Previous Topic:	Adding bundle to dm server to extend tomcat
Next Topic:	Classloader issues with third party bundles and RMI

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 18 10:00:25 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter