Thank you for pointing that out! I'll incorporate that in my remarks. Kind regards Jens
On 02.06.2010, at 21:09, Richard S. Hall wrote: > On 6/2/10 14:56, Jens Lauterbach wrote: >> Thank you for your answer Richard. >> >> The reason why I ask this question is that I am working on my thesis about >> OSGi right now. Part of this thesis involves the whole class loading process >> and I just wanted to provide some more information to the reader than simply >> saying, that the OSGi framework is somehow handling this issues. >> >> Again. Thank you very much. >> > > Ok, well, keep in mind, the way the Felix framework does this is purely an > implementation detail. You cannot assume that some other framework does it in > even a remotely similar way. For example, I believe some frameworks keep > track of which packages are associated with which wires and only ask the > appropriate wire (i.e., the delegation behavior is implemented external to > the wire). And in reality, some likely implement it without actually have a > physical representation of a "wire" since this is more a conceptual entity > than a spec defined entity. > > -> richard > >> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
