On 15/01/2008, Karl Pauls <[EMAIL PROTECTED]> wrote: > > > I am hoping that if I add my library jars in system classpath and set > > bootdelegation="*", the library jar's content will be automatically > > available to other bundles even if I don't set > > org.osgi.framework.system.packages property. Is this not going to work? > > No. It doesn't work like this. You still need to make the packages > your bundles explicitly import available form the system bundle (i.e., > add them to the system.packages property). The bootdelegation is > needed only for the case where you want to make packages available to > bundles _without_ them needing to import them. However, if they import > them then it doesn't work. In other words, this is not a bug in Felix > but you will have to adjust your assumptions. > > What happens in your case is that the bootdelegation=* effectively > short-cuts the whole resolving process and makes Felix use the > bootclassloader _all_ the time. That one, however, doesn't know about > classes that come from a bundle -- hence, the CNFE. As Felix > Meschberger mentions, do try to avoid using the bootdelegation feature > unless your really need it - it's not a convenience feature but a last > resort.
but the spec does not say the search should end if a non java.* bootdelegation class can't be found in the parent classloader, which is what Felix does - it treats all packages in bootdelegation the same. the earlier part of the spec explicitly says the search ends at the parent for java.* packages, but makes no mention of stopping there for non java.* packages - this suggests to me that it should continue and search imports rather than stopping at the parent this appears to be the behaviour in the reference implementation and a couple of other frameworks I've tested. Regardless of the merits of bootdelegation, I still think this is something we need to fix (or clarify in the spec). regards, > > Karl > > > Thanks, > > Sahoo > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > Karl Pauls > [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Cheers, Stuart
