> 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. Tom
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
