All,
I have some questions regarding bundle class path resolution in the
presence of fragments. I am not finding the answers obvious from the
specification.
The example given in 3.8.1 is:
----
A: Bundle-SymbolicName: A
Bundle-Classpath: required.jar,optional.jar,default.jar
content ...
required.jar
default.jar
B: Bundle-SymbolicName: B
Bundle-Classpath: fragment.jar
Fragment-Host: A
content ...
optional.jar
fragment.jar
----
and the effective bundle class path is given as
----
require.jar, optional.jar, default.jar, fragment.jar
----
All well and good. In the example there are no "duplicates" or "."
defaults. In the following examples I have host A, fragment B, and
sometimes fragment C. Assume that the fragment B bundle identifier is
less than C's (i.e. B was installed before C).
1) What if fragment A is the same, but B is defined as
----
B: Bundle-SymbolicName: B
Bundle-Classpath: fragment.jar
Fragment-Host: A
content ...
default.jar
optional.jar
fragment.jar
----
(i.e. the fragment also provides "default.jar").
Is the effective bundle class path the same, or does it become
----
require.jar, optional.jar (from A), optional.jar (from B),
default.jar, fragment.jar
----
In other words, do the fragments augment existing class path entries
of the host, or does the host always hide an identical fragment
library if it is also present in the host? If the latter, does this
shadowing proceed down the ordered list of attached fragments so that
only the first optional.jar encountered becomes part of the effective
class path?
2) Go back to the original spec example. What if host A's bundle
class path is ".,required.jar,optional.jar,default.jar"?
I assume that this means the first class path entry would be that of
bundle A's "root".
2a) Similar to 1), would fragment B's "root" be the second entry?
2b) If so, then does this imply that a "." in the host plugin "brings
in" the root of all attached fragments?
2c) If not, does this imply that a "." in the host plugin "hides" "."
in every attached fragment?
2d) In any case, is "." special for the host, or does it also apply
to all fragments (i.e. a fragment including "." in its bundle class
path effectively brings in the root directory of the host and any
other fragments)?
3) Assume again the example from the spec, except that now there is also
----
C: Bundle-SymbolicName: C
Bundle-Classpath: fragment.jar
Fragment-Host: A
content ...
fragment.jar
----
3a) Does the effective bundle class path become
----
require.jar, optional.jar, default.jar, fragment.jar (from B),
fragment.jar (from C)
----
3b) If fragment B did *not* actually contain fragment.jar, would the
effective bundle class path become
----
require.jar, optional.jar, default.jar, fragment.jar (from C)
----
In other words, can a fragment provide "extending" entries to
declarations made in other fragments?
4) Now assume:
----
A: Bundle-SymbolicName: A
Bundle-Classpath: required.jar,optional.jar,default.jar
content ...
a.jar
B: Bundle-SymbolicName: B
Bundle-Classpath: b.jar
Fragment-Host: A
content ...
b.jar
c.jar
C: Bundle-SymbolicName: C
Bundle-Classpath: c.jar
Fragment-Host: A
content ...
c.jar
----
What is the effective bundle class path? Specifically, would fragment
B's c.jar appear in it because fragment C declares it, even though it
is a "later" fragment.
Thanks in advance. Sorry for the length, but I believe that in such
cases concrete examples are better. (I hope I don't have typos that
obscure my questions ;-)
/djk
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
