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
- 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.
Peter Kriens <Peter.Kriens@xxxxxxxx> Sent by: equinox-dev-admin@xxxxxxxxxxx
03/29/2004 12:37 PM
Please respond to
Thomas Watson <tjwatson@xxxxxxxxxx>
Re: [equinox-dev] Attaching
fragments to resolved hosts.
Hmm. Fragments seem way too powerful. We seem to hopping
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.
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
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
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
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
34 Place René Nelli
34670 Baillargues, France
equinox-dev mailing list