We've recently added a new bundle to our osgi project, which was the result of 'osgifying' a non osgi compatible bundle ourselves and it appears to have caused some dependency conflicts with an existing bundle.
This is not completely unexpected but the problem is that instead of printing out any errors virgo is just crashing and giving us a dump file, which I'm having trouble getting any useful information out of.
Is crashing when there's a failure to resolve dependencies expected behavior? And if it is, is that any kind of clue as to what kind of problem I should be looking for?
I've attached the summary.txt and thread.txt from the dump.
Crashing is not expected behaviour. A resolution failure is supposed to drive a dump and then fail the deployment in question. During the dump, each dump contributor gets a chance to contribute a file to the dump. In particular, the OSGi (wiring) state and region digraph should be dumped so they can be analysed offline using the web admin console.
In addition to attaching the logs, it would be great if you can narrow this scenario down to something reproducible with a small number of bundles. Often the root cause becomes obvious during that narrowing down process. But if the root cause does not become apparent, you'll have something we can look into further, possible as input to a bugzilla if appropriate.
I now know what's causing the problem, but the why is still unclear. We use some XML schemas and jaxb to generate classes which we Marshall to and from XML. It so happens that we're supporting two versions of these schemas simultaneously.
So now we have two packages com.foo.bar and com.foo.bar2 that have the same class names in them, and one particular bundle doesn't seem to play nicely with this.