[EMAIL PROTECTED] wrote on 03/11/2008 02:16:04 AM: > > On Mar 10, 2008, at 4:51 PM, Mirko Jahn wrote: > > > On Mon, Mar 10, 2008 at 11:34 PM, Alan Cabrera <[EMAIL PROTECTED]> > > wrote: > >>
Your original question: > Is it possible for two different versions of a Fragment to be attached > to two different hosts? Yes two different versions of a fragment can be attached to two different hosts as long as the fragments are not singletons. But two different versions of a fragment cannot be attached to the same version of a host. The later is a clarification that will be in the next version of the specification. > Is it possible to attach a Fragment to a host that's already resolved? The spec is not 100% clear here. Originally we defined fragments as having the ability to be attached dynamically to a host bundle that is already resolved without forcing the host bundle to refresh. This would be nice to do but it does cause a number of issues. - Fragments that add new constraints cannot be allowed to attach dynamically. It is not possible to insert new constraints wires into the class loader of the Host because this could change the wires in the host in incompatible ways at runtime. - There were also concerns with adding content dynamically to packages already exported by the host. Especially with split packages where a fragment may all of a sudden shadow a class from another bundle that exports the package. This is an extreme corner case, but there were too many questions to answer before we could make a definitive spec which allowed dynamic attachment of fragments to already resolved hosts. Frameworks are not required to allow dynamic attachment of fragments to an already resolved host. But I think there is some wiggle room in the spec that allows dynamic attachment of fragments if the framework wants to do some extra consistency checks. > > >> IIUC, Fragments become resolved as a byproduct of the host, to which > >> it has been attached to, becoming resolved. If this is true then > >> resolving Fragments should be essentially a do nothing operation? > > Well, fragments don't have their own class loader and they are seen as > > part of the host. I think the spec is not 100% precise here (unless I > > overlooked something), but I suspect it to be the same behavior as > > with updating of already attached fragments. Here the spec states that > > the host has to be refreshed. The spec also states that attaching is > > part of the resolving process of the host, so I guess the host has to > > be resolved again, but I am not sure on that one. Maybe someone else > > can answer that one better. > > Re-reading the spec I think that the only consistent interpretation is > that both hosts fragments can be resolved. Yes you are correct. > > > 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. > > > 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. > > > 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
