On Tue, Mar 11, 2008 at 2:50 PM, Thomas Watson <[EMAIL PROTECTED]> wrote:
> > > One thing I was always curious about is the resolving process together > > > with fragments. The spec states that the class path of the host has to > > > be searched first, so far so good, but how does this relate to the > > > whole lookup process? When we are using a fragment will first the > > > lookup process of the host finish from beginning to the end > > > (Import-Package --> Require-Bundle -->...) before the fragment is > > > asked or will it be like a ping pong affect (look for Import-Package > > > in the host before the fragment, then look for Require-Bundle in the > > > host before the fragment and so on). > > > > A fragment's imports, required bundles, and exports that do not > > conflict are added to the host bundle's set when it's being attached. > > The resulting wires are added to the host bundle. These are added to > > the end of the existing set of wires and so the host bundle's wires > > are searched first. So, it's kinda like the latter. > > Yes, and to be clear all external constraints (Import-Package and > Require-Bundle) from the host and attached fragments are searched before > searching the local classpath of the host and fragment bundles. Well, I suspected that. The question now is, if an Import-Package of the Fragment is used before a Require-Bundle lookup strategy of the host (like an alternating lookup strategy for each step in the lookup table, where the host is always asked first)? Actually that's what I would expect. If so, I am currently not quiet sure, if I like it or hate it. :-) There are some implications coming with that (not valued). 1. the fragment can inject a lookup of the host defined as a Require-Bundle with an Import-Package 2. local resources/class in the host can be replaced via custom import statements and a fitting provider bundle 3. dynamic imports defined in the host bundle can be seeded by the fragment. In general, these are interesting possibilities, but if I look at the robustness of the entity "bundle" it becomes weaker. Looking at the desired deterministic behavior for components f.i. in Software Product Lines, this might lead to a too weak definition of a bundle. Well, as I said, I am not sure yet. > > > If the later is true, a fragment > > > can be used to replace an internal class by defining an Import-Package > > > (or Require-Bundle) statement and providing that one with a third > > > bundle. If so, this might be useful as a pattern in order to replace > > > corrupted implementations without violating licenses, because you do > > > not have to touch the 3rd party bundle. If it is the first behavior, > > > it is fine as well, because with that a bundle is more robust and > > > resistant against other potentially malicious bundles. > > > > Host bundles are protected by perms that are required for a fragment > > to attach itself. So, for the latter, you get the best of both worlds. > > The fragment also must have permission to Import-Package and > Require-Bundle. Yes, sure! Each fragment has it's own ProtectionDomain (besides extension fragments) and thus have to have their own permissions, but I was actually more talking about a typical application like Eclipse, where no SM and thus no permission checks are available, but anyway. Thanks for the answer! > > > > > > > It would just > > > be good to know. Sorry for bringing up my question in your thread, but > > > I though it kinda fits in here. > > > > No worries. > > > > > > Regards, > > Alan > > > > Tom > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- -- Mirko Jahn Heidelberger Str. 51 69126 Heidelberg Fon: +49 [0] 6221 - 431 28 58 Mobile: +49 [0] 173 211 41 94 E-Mail: [EMAIL PROTECTED] Web: http://www.mjahn.net _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
