I thought I'd try a similar example in Virgo for comparison. Here are Virgo's diagnostics:
Unable to satisfy dependencies of bundle 'org.example.foo.xydata' at version '0.0.0': Cannot resolve: org.example.foo.xydata
Resolver report:
Uses violation: ⟨Import-Package: org.example.foo.bar.datastore; version="0.0.0"⟩ in bundle ⟨org.example.foo.xydata_0.0.0[1301563814803]⟩
Found conflicts:
package 'org.example.foo.util.verify_1.0.0' in bundle 'org.example.foo.platform.util_0.0.0[1301563814806]' used by 'org.example.foo.bar.datastore_0.0.0' in bundle 'org.example.foo.bar.datastore_0.0.0[1301563814805]'
conflicts with 'org.example.foo.util.verify_2.0.0' in bundle 'org.example.foo.framework_0.0.0[1301563814804]' imported by bundle 'org.example.foo.xydata_0.0.0[1301563814803]'
(The numbers in square brackets are bundle ids - they are enormous because Virgo is attempting resolution in a "side state". Bundles with enormous ids have either been deployed directly or auto-installed from the Virgo repository and are in the process of being resolved. They are committed to the OSGi framework only if the directly deployed bundle(s) can be resolved successfully.)
The Virgo formatting isn't quite as pretty as Felix's, but it looks reasonable on a wide terminal window. However, there are some subtle differences:
- Felix dumps out the dependency chains whereas Virgo does not attempt that. We had in mind examples where the dependency chains are unmanageably long, i.e. those where good diagnostics really are essential. But having seen Felix's diagnostics, we would like to dump out the chains in simple cases. On the other hand, that area of code is pretty complex, so this is not something we'll be rushing to do.
- Felix depicts wirings from import to export which could be especially useful for newcomers to OSGi.
- The Felix diagnostics are built in to the framework whereas non-Virgo users of Equinox do not get the Virgo diagnostics.
- The Virgo diagnostics highlight the fact that there is a uses violation whereas Felix leaves the user to infer that from the rest of the message. It would be nice if Felix was more explicit because there are other reasons a bundle cannot be resolved.
- Felix highlights the duplicated package whereas Virgo highlights the import that encountered the uses constraint. Virgo is designed to cope well when there are multiple duplicated packages. It's not clear what the Felix diagnostics would look like in such cases.
Anyway, I'm really pleased that we are starting to see some stiff competition on diagnostics. This will help OSGi users enormously.
Postscript
Bug 341460 is fixed in the Virgo 3.0 line. The admin console now displays the same diagnostics that were printed to the console.
Hi Glyn,
ReplyDeleteGreat to see, that Virgo will get better diagnostics. Does this also help for diagnosing problems with optional imports? I have a problem with spring and hibernate, which I suspect is a uses constraint problem. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=320454 and https://jira.springsource.org/browse/SPR-7003 for an example.
Regards,
Wolfgang
Actually those diagnostics are already available in Virgo 2.1 and in dm Server 2.0. Yes, you can see dropped optionals in the OSGi state explorer in the admin console.
ReplyDeleteGreat diagnostics! Agree it is good that we get more work in this area.
ReplyDeleteAny change of publishing the dump format so that this can be shared between framework implementation. Would be great for tool developers.
Thanks, kind regards,
Peter Kriens
I'm afraid the dump doesn't have a standard format. It consists of two files in the directory created when Virgo takes a dump: a persisted Equinox State and a persisted region digraph. The region digraph code is moving into Equinox, so both will be Equinox "standard" very soon, but no more standard than that.
ReplyDelete