Hi, Yup that was it. I got a new build of WTP and this seems to have gone away. I was pretty close, I just didn't realize eclipse set the delegation property to * by default because I was on an eclipse build that already had the patch for the new classloading fix that was put in.
Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] David M Williams/Raleigh/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/29/2007 01:07 PM Please respond to OSGi Developer Mail List <[email protected]> To OSGi Developer Mail List <[email protected]> cc Subject Re: [osgi-dev] Classloading Question You might read bug 167695 to see if it helps https://bugs.eclipse.org/bugs/show_bug.cgi?id=167695 It might help with some practical advise specifically related to xml conflicts, not sure it answers your spec questions. Andrew Eberbach/Durham/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/29/2007 12:20 PM Please respond to OSGi Developer Mail List <[email protected]> To [email protected] cc Subject [osgi-dev] Classloading Question 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. 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. 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. 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? 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? Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
