We did battle some of the same issues in the bug report David mentioned in a separate post (https://bugs.eclipse.org/bugs/show_bug.cgi?id=167695). I think your errors sound very similar. What build of Equinox you are using? Do you set the context classloader at any point in your bundle?
See more comments below. Tom [EMAIL PROTECTED] wrote on 01/29/2007 11:20:28 AM: > Hi, > > I'm currently battling a classloading problem. I'm in Eclipse (Equinox) > and I'm trying to load some XML classes. Now, the classes in question are > from javax.xml and there is a xerces2.8 bundle that is in the dependency > list. One of the classes tries to load a javax.xml class and gets a > ClassCastException. What does the stacktrace look like? I assume you are calling some SAX/DOM factory to get an instance. > I turn on -verbose:class and see that the class in > question is being loaded by both the System class loader and the xerces > bundle Classloader and at some point an interface and a implementation are > put together and the thing fails. Now if I set the bootdelegation system > property to javax.xml.* and org.apache.xerces.* everything is loaded from > the system classloader but I get an IncompatibleClassChange error since > I'm guessing the classes were compiled against a different version. I would be curious to know if just setting bootdelegation to * would help. There are other packages related to JAXP that you may need org.w3c.* and org.xml.* > > So I've been going through the spec and I'm a little confused about the > flow for classloading. Figure 24, page 56 of the R4 spec. In java, in > general, the parent is consulted before anyone else. This is not the case > in OSGi, right? But, the parent can be consulted if that system property > is set and the class matches one of the package patterns. So this implies > to me that even though the bundle got something from the parent. But I > looked at the bundles and saw that they don't do any non-bundle dependency > classloading that would make it do a wire load or something like that. If any of the bundles in your system reexport the system.bundle (or org.eclipse.osgi) and you depend on one of these bundles then you will get a wire to the all the packages exported by the system.bundle. This includes things like javax.xml because the system.bundle exports all packages in the specified EE (J2SE-1.4, J2SE-1.5 etc.). On such example is the org.eclipse.core.runtime bundle. > So > then I'm looking through the system properties and I find: > > osgi.compatibility.bootdelegation=true > > (more info here: > http://wiki.eclipse.org/index.php/Equinox_Boot_Delegation) > > So is it the case that it tries to load some class, can't find it and then > falls through to this non-standard behaviour? At that point it gets a > different version of the class from the parent, tries to match the > interface to the class and gets the class cast exception? > Maybe, but I'm doubtful. If this is true then setting osgi.compatibility.bootdelegation=false should result in ClassNotFoundExceptions or NoClassDefFoundErrors. This seems more like a problem with context class loaders to me. > Finally, I'm curious about secion 3.8.5 about the parent classloader. It > says that there's a system property that shows which packages are exported > from Bundle 0. I looked at this list and javax.xml is in there. Is this > only there for symmetry reasons so that if a bundle imports a package (via > Import-Package, instead of depending on a specific bundle) that the system > bundle can expose these non java.* classes as a possible exporter? The system bundle (bundle 0) should export all known available packages for the execution environment you are running. On J2SE-1.4 or higher this includes the javax.xml package. This is done to allow bundles to use Import-Package to access these packages.
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
