On Mar 11, 2008, at 6:50 AM, Thomas Watson wrote:
[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.
I think that it's unfortunate that the word "version" has crept into
this part of the spec. A better word would be generation. Does this
not sound better:
Yes, two different generations of a fragment can be attached to two
different hosts as long as the fragments are not singletons. But two
different generations of a fragment cannot be attached to the same
generation of a host.
Ideally, if a bundle was updated its version would increment but this
does not necessarily happen, IIUC. If this clarification does not
make sense then I must have a mental disconnect somewhere.
> 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.
Would this not be covered by classifying these wires as "conflicting"
w/ the host bundle and so it would not be added? I understood
attachment of a fragment to be a two step process. Add imports, et
al, that did not conflict. Then try to resolve the resulting
candidate host in the existing class space.
The fragment developer knows about the host and should design the
imports, et al, to not conflict with it. The framework's job is to
make sure that the fragment does not bork the host in any obvious way.
If my interpretation is correct, then I think that the developer would
be better served if any conflict in the imports, et al, would cause
the fragment to not be loaded all together. The developer put those
imports, et al, with a specific goal in mind. It's the frameworks job
to tell the developer that it cannot accommodate the developer's wishes.
This rant is along the similar vein that I have with some of the
methods that take strings that have filter patterns that can be
malformed; they silently return nothing instead of consistently
throwing a malformed pattern exception like some of the other methods
do.
- 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.
Not an extreme corner case, IMO. Mirko was already espousing its use
to live patch a host bundle. IMO, this is crazy dangerous, IIUC.
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.
What would these checks be? I am very curious.
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
