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


On point 1:  Seems we are in agreement.

On point 2:  Sounds good too.

The combo of points 1 and 2 should leave room for someone who wants to implement a classloader that does keep track of the packages it loads to dynamically attach fragments where their attachment would not affect preexisting loading patterns.  I'm not proposing that we implement that but the spec should allow it.

Jeff


Thomas Watson <tjwatson@xxxxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

03/30/2004 09:05 AM

Please respond to
equinox-dev

To
equinox-dev@xxxxxxxxxxx
cc
Subject
Re: [equinox-dev] Attaching fragments to resolved hosts.






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


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


- Perhaps we can leave it open to the implementation in the same way as refreshPackages is spec'd such that a shutdown/restart is an acceptable implementation. Bascially state thta under no circumstances can a fragment cause a change to preexisting classloading and implementations are free to attach dynamically or require a refresh.


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


Thomas Watson



Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

03/29/2004 08:32 PM
Please respond to equinox-dev

       
       To:        equinox-dev@xxxxxxxxxxx

       cc:        

       Subject:        Re: [equinox-dev] Attaching fragments to resolved hosts.





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


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


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


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


- Perhaps we can leave it open to the implementation in the same way as refreshPackages is spec'd such that a shutdown/restart is an acceptable implementation. Bascially state thta under no circumstances can a fragment cause a change to preexisting classloading and implementations are free to attach dynamically or require a refresh.


Jeff


Peter Kriens <Peter.Kriens@xxxxxxxx>
Sent by: equinox-dev-admin@xxxxxxxxxxx

03/29/2004 12:37 PM

Please respond to
equinox-dev


To
Thomas Watson <tjwatson@xxxxxxxxxx>
cc
equinox-dev@xxxxxxxxxxx
Subject
Re: [equinox-dev] Attaching fragments to resolved hosts.









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

KISS!

Kind regards,

  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.  Butshould we
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 Bundle X 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

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/equinox-dev