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

[Olivier Gruber <ogruber@xxxxxxxxxx>]

Indeed, predictability is the way to
go... and fragments need a little rethinking for that.
I have an easy way to think about fragments:
a fragment is an update to their host from
an admin perspective and a structuring/packaging
mechanism from a programmers' 
perspective.

Hence, installing a fragment is equivalent
to updating its host. That's the simplest and most
predictable semantics. Like when a bundle
is update, it is stopped, reloaded, and restarted. The same
should happen when a fragment is added---always,
no optimization. Otherwise, 
we just have potentially different behaviors
between updates and restarts. 
With this perspective, it is quite normal
to allow changes in imports and exports. 
It is also quite normal to expect fragments
to need initialization of their own, therefore having 
activators. Having activators, we will
need a start level mechanism within the host bundle to allow
to control fragment initialization as
we needed to control order of bundle initialization.

From a programmer's point of view, fragments
are a way to structure bundles used in different context.
NL is one example. Another example would
be different OS and therefore different native
libraries. Another example is using
either a native library or a Java implementation depending on the 
environment. Another example would be
to allow for JRE or profile differences. For instance, different 
fragments may  either bring an
AWT or an SWT implementation, or a file implementation versus a 
database one (JDBC). A fragment is therefore
likely to need its own activator, to do its own specific 
initialization, lookup needed services,
register services, etc. With fragments, split packages work the 
proper way, keeping the Java semantic
of package-level access (same class loader). Also, fragments 
allows avoiding export/import statements
for internal packages.

In that sense, fragments are not trying
to be bundles, they are parts of bundles. I believe it would be 
simpler if fragments would behave as
follows:

        -
no optimization, ALWAYS restart the host
        -
allow fragment activators, chained to their host one. 
         
We need a start level for fragments within their host, including pre versus
post the activator of the host.
        -
fragment may have imports/exports, they are merged with their host.
        -
fragments are NOT shared between different host versions (loaded by each
host class loader).

Best regards,

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> Sent by: equinox-dev-admin@xxxxxxxxxxx 03/29/2004 09: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