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
