Hey Richard, thank you for your help so far. I searched the latest Core Specification for some text stating that the framework/class loader is responsible for checking that the requested class is in an exported package. Can you point out where to find it or is it not in the spec because it's kind of common sense to do those checks?
I read through the module layer specification and found nothing. "Class Loading Architecture" and "Runtime Class Loading" looked promising, but I couldn't find anything in there. Kind regards Jens On 02.06.2010, at 19:37, Richard S. Hall wrote: > On 6/2/10 13:25, Jens Lauterbach wrote: >> Hello, >> >> I am trying to figure out how two bundles are "wired" together. Bundles can >> import and export packages. As far as I can tell from diving into the code >> the importing and exporting packages are wired together >> (org.apache.felix.framework.resolver.WireImpl) and not the bundles itself. >> If a class is going to be loaded the actual wire is responsible for checking >> if the requested class is in one of the exported packages. Only if the class >> is in one of the exported packages the wire is going to call the exporting >> bundles class loader. >> >> Are those assumption correct? >> >> What I am trying to find out is, who is responsible for checking that only >> class can be imported, that are actually part of a exported package and not >> of the internal implementation (which is hopefully not exported). >> > > Basically, that's correct. > > A wire connects a bundle to another bundle providing some capability from > which it can load classes. A wire is specifically associated with its > importer/requirement on one end and the exporter/capability on the other end. > The wire then implements the associated behavior of what it means to be a > wire to connect the given requirement to the given capability (e.g., wires > for packages throw an exception if the package matches but the class is not > found, since this should terminate the search, whereas this isn't true for > require-bundle wires). This also includes checking if a given class is > allowed to be exposed from a given bundle. > > It's not really clear why you want to know the implementation details, > though, since the spec information should be sufficient. The only thing a > bundle really needs to know is that the spec says it will be given access, > how is not so important. > > -> richard > > > >> Kind regards >> Jens >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
