I agree the spec can be improved here. Alan, can you please open at https://www.osgi.org/bugzilla/ to address this in the OSGi specification. Thanks.
I think your modified steps 5 and 6 are an improvement. But I still think
step 5 is unclear.
5) When we load a class/resource we first search through the host class
path entries. We iterate over each path token in this host class path.
For each path token we first search the host and, if not found, the
fragments. When the class/resource is found we stop the search. If it not
found we iterate to the next path token from the host class path and
repeat. If we run out of path tokens then we move on to step 6.
I think the sentence "For each path token we first search the host and, if
not found, the fragments." is vague
Take the following example:
BSN: host
Bundle-ClassPath: fragment.jar, host.jar
content ...
host.jar
BSN: fragment1
Fragment-Host: host
content ...
host.jar
fragment.jar
BSN: fragment2
Fragment-Host: host
content ...
host.jar
fragment.jar
In this example, I think the spec is clear that the host.jar from fragment1
and fragment2 are ignored. What about the fragment.jar from fragment1 and
fragment2, do we search both fragment.jar files from fragment1 and
fragment2 or just the fragment.jar from the fragment with the lowest bundle
ID? Currently the RI is implemented such that only the fragment with the
lowest bundle ID is searched.
You asked about my statement "The search does not terminate at the first
entry found, instead the search continues until all attached fragments have
been searched".
I was referring to the search for class path entries in the host and
attached fragments. I think the spec is unclear on if the class path entry
search is terminated at the first entry found in a fragment or whether it
should continue and collect all class path entries found in the attached
fragments. The spec is clear that fragments are *not* searched if the
class path entry is found in the host bundle, but I do not think it is
clear on the case where the host class path entry is not found.
Tom
From: Alan Cabrera <[EMAIL PROTECTED]>
To: OSGi Developer Mail List <[email protected]>
Date: 04/01/2008 12:38 AM
Subject: Re: [osgi-dev] Bundle-Classpath and fragments
On Mar 31, 2008, at 8:07 AM, Thomas Watson wrote:
> I'm a bit confused by how fragments contribute to the overall
search
> order as described by section 3.8.4. If I understand correctly the
> fragment's classpath gets appended to the host's to create a new
and
> improved class path that *both* fragment and host use.
This is correct, a single class loader is shared between the host
and all attached fragments. A fragment's Bundle-ClassPath is
searched
after the entries specified on the host Bundle-ClassPath.
I think there is some confusion about where to find the actual
entries
specified on the host and fragment classpaths.
When locating a class path entry in a bundle, the Framework must
attempt
to locate the class path entry relative to the root of the bundle’s
JAR.
If a class path entry cannot be located in the bundle, then the
Framework must attempt to locate the class path entry in each of the
attached fragment bundles. The attached fragment bundles are searched
in
ascending bundle ID order. Once the class path entry is found in an
attached fragment no other fragments are searched for the classpath
entry.
The last sentence is missing from the spec. I also think the spec
may need some clarifications on where to look for classpath entries
that are specified in the Bundle-ClassPath headers specified in
fragment bundles. You seem to indicate that a Bundle-ClassPath
entry specified in a fragment must be searched for in the host
bundle. This is not the case. When a fragment specifies a
Bundle-ClassPath (i.e fragmentContent.jar) then that entry is only
searched for in the fragment. The host bundle and other attached
fragments are not searched for the entry (i.e fragmentContent.jar).
> To make the
> scenario in section 3.8.1 work it seems that each element in the
new
> class path must be used to search the host and then fragments. If
the
> resource is not found with that element, the framework should then
> iterate on to the next element, searching the host and then the
> fragments.
Again I think there is some confusion here about where to search for
entries specified in fragment's Bundle-ClassPath headers. We do not
want to first search the host for the entries specified on fragment
bundle classpaths because the search for the entry is terminated on
the first one found. For example, a fragment with no inner jars
would
use '.' as its classpath. We would always find '.' in the host and
that would cause '.' from the fragment to be ignored.
>
> This means that steps 5 and 6 really need to be merged into a
single
> step.
Not really, as it stands today these need to be separate steps
because
the Bundle-ClassPath entries from the fragments only search the
individual fragment's content for the entry.
Your interpretation of the spec seems to be that each
Bundle-ClassPath
entry, whether it is specified in the host or an attached fragment,
is
located by searching the host and then all attached fragments. The
search does not terminate at the first entry found, instead the
search
continues until all attached fragments have been searched. Each
entry found is added to the overall classpath of the class loader.
I think this would be an interesting (and perhaps more clear)
definition of the bundle class path. But as it stands today this
was not the intended interpretation.
I suggest you open a bug against OSGi to continue the discussion.
I don't understand your statement "The search does not terminate at the
first entry found, instead the search continues until all attached
fragments have been searched".
So, to put this in my own words.
When resolution is done and we've added N fragments we then have N+1 class
paths. One for the host and N for each fragment.
5) When we load a class/resource we first search through the host class
path entries. We iterate over each path token in this host class path.
For each path token we first search the host and, if not found, the
fragments. When the class/resource is found we stop the search. If it not
found we iterate to the next path token from the host class path and
repeat. If we run out of path tokens then we move on to step 6.
6) If it is not found, we search through each of the fragments' class path
entries. Each path token is restricted to the fragment and no other
bundles.
I think where I got confused is that the spec vaguely states that all sorts
of fragment things get appended to the host; I assumed that this was the
case for class paths and working though the example in 3.8.1 I saw no
conflicts with this view. The last sentence reinforces this view:
"When bundle A is resolved and the fragment bundle B is attached then the
bundle class path for the bundle A is:
required.jar, optional.jar, default.jar, fragment.jar"
Two things need to be done, imo. Explicitly list what gets appended and,
in 3.8.1, explicitly state that there are N+1 class paths and the host
class path "spills" over across the other fragments while the fragment
class paths are confined to their respective fragments.
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
