[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [equinox-dev] Attaching fragments to resolved hosts.

The MAY worries me ...

Kind regards,

     Peter Kriens

TW> - The solution to your example is quiteas easy as you say.
TW>  There is no easy way to know that X includespackage foo (assume
TW> it is in the PRIVATE class space).   You coulddo an implementation
TW> trick where you know what packages you have loadedfrom yourself
TW> but that may not be much fun to track.  Hmm, does theclassloader
TW> know this?

TW> On the J2ME Foundation library you candefine Packages in you
TW> classloader to keep track of what packages you haveloaded from a
TW> bundle classloader but that will not work on ee.minimum. But what
TW> you say just reinforces my view.  If a fragment
TW> imports/exportsadditional packages or requires additional bundles
TW> then it should not beallowed to attached to a resolved host even
TW> if it can logically be attachedto the end of the host.  These
TW> types of fragments should only be allowedto attach to a host when
TW> the host is refreshed or the framework is restarted. If we inforce
TW> these rules then we should not have to keep track ofthe packages a
TW> bundle classloader has loaded because there would be noway for a
TW> fragment to attach itself and cause a package to be overridenin
TW> the middle of a host's resolved/active state.

TW> - Perhaps we can leave it open to theimplementation in the
TW> same way as refreshPackages is spec'd such that ashutdown/restart
TW> is an acceptable implementation. Bascially state thtaunder no
TW> circumstances can a fragment cause a change to preexisting
TW> classloadingand implementations are free to attach dynamically or
TW> require a refresh.

TW> I would like to consider this option. But I think we must
TW> spec out what a fragment can and cannot do toa resolved host.  In
TW> the spec we should make it possible for an implementationto choose
TW> not to attach a fragment to a resolved host without refreshingthe
TW> host.  Something like "The Framework MAY attach a fragmentbundle
TW> to a resolved host if the following conditions are true
TW> ...." "When a host bundle is refreshed or the Framework is
TW> restartedall resolved fragment bundles MUST be attached to their
TW> resolved host(s).

TW> Thomas Watson

TW> Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
TW> Sent by: equinox-dev-admin@xxxxxxxxxxxxx/29/2004 08:32 PM
TW> Please respond to equinox-dev

TW>         To:       equinox-dev@xxxxxxxxxxx
TW>         cc:       
TW>         Subject:       Re: [equinox-dev] Attaching fragmentsto resolved hosts.

TW> Predictability is the way to go.  A couple of notes:

TW> - the general theory of the "fragments must be attached in
TW> order"rule goes something like "a fragment which changes
TW> preexisting classloadingbehaviour cannot be attached until the
TW> host is refreshed"

TW> - The solution to your example is quite as easy as you say.
TW>  Thereis no easy way to know that X includes package foo (assume
TW> it is in thePRIVATE class space).   You could do an implementation
TW> trick whereyou know what packages you have loaded from yourself
TW> but that may not bemuch fun to track.  Hmm, does the classloader
TW> know this?

TW> - The NL usecase is compelling as Peter notes.
TW>  Unfortunately, ittoo suffers from these problems since the NL
TW> resources are loaded by theclassloader based on the same package
TW> import/requires rules.

TW> - Perhaps we can leave it open to the implementation in the
TW> same way asrefreshPackages is spec'd such that a shutdown/restart
TW> is an acceptableimplementation. Bascially state thta under no
TW> circumstances can a fragmentcause a change to preexisting
TW> classloading and implementations are freeto attach dynamically or
TW> require a refresh.

TW> Jeff

TW> Peter Kriens <Peter.Kriens@xxxxxxxx>
TW> Sent by: equinox-dev-admin@xxxxxxxxxxxxx/29/2004 12:37 PM

TW> Please respond to
TW> equinox-dev

TW> To

TW> Thomas Watson <tjwatson@xxxxxxxxxx>cc

TW> equinox-dev@xxxxxxxxxxxxxxxxxx

TW> Re: [equinox-dev] Attachingfragments to resolved hosts.

TW> Hmm. Fragments seem way too powerful. We seem to hopping between two
TW> thougts. I always liked the localization use case which seems simple
TW> and straightforward. A fragment is not a bundle and should not try
TW> to become one in my opinion. I agree that it should not be allowed to
TW> to do anything outside the scope of its host.


TW> Kind regards,

TW>     Peter Kriens

TW>> In the Equinox OSGi Framework we allowa fragment to attach
TW>> itself to a resolved host only if it can logicallybe appended to
TW>> the end to of the the bundle classpath of the host.  Butshouldwe
TW>> allow fragments to be attached to resolved or active hosts ifthe
TW>> fragment imports additional packages or requires additional
TW>> bundles? The current Equinox Framework allows for this to happen.

TW>> This can lead to unpredictable behaviorwith respect to
TW>> loading classes and resources from a host while it is
TW>> resolved. For example, a bundle X includes a package foo and does
TW>> not importany packages or require any bundles.  Bundle X is
TW>> resolved and startedwithin the Framework.  Fragment Y is a
TW>> fragment to Bundle X and itrequires Bundle Z which provides
TW>> package foo.  If Fragment Y is attachedto a resolved BundleX then
TW>> Bundle X will all of a sudden start loadingpackage foo from Bundle
TW>> Z because it was required by Fragment Y.

TW>> I suggest the Framework should not allowa fragment to attach
TW>> to a resolved or active host bundle if the fragmentimports or
TW>> requires anything that is not already imported or required bythe
TW>> resolved host bundle.  If a host bundle is refreshed then it
TW>> willbecome unresolved and re-resolved, at that time the new
TW>> fragment bundleshould be attached to the host bundle.

TW>> Thomas Watson

Peter Kriens                              Mob. +46705950899
34 Place René Nelli                       Tel. +33467871853
34670 Baillargues, France                 AOL: pkriens