[
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@eclipse.org03/29/2004 08:32 PM
TW> Please respond to equinox-dev
TW>
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@eclipse.org03/29/2004 12:37 PM
TW> Please respond to
TW> equinox-dev
TW> To
TW> Thomas Watson <tjwatson@xxxxxxxxxx>cc
TW> equinox-dev@eclipse.orgSubject
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> KISS!
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
