On 6/3/10 5:59, Jens Lauterbach wrote:
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.
Perhaps it is common sense. The spec states what the framework will do,
which is provide a bundle access to its imported packages and only
expose its exported packages, which conversely is stating that a bundle
shouldn't have access to stuff it doesn't import and won't expose stuff
it doesn't export. Exactly how this is accomplished is not stated in the
spec.
-> richard
"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: [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]
