On Apr 1, 2008, at 6:51 AM, Thomas Watson wrote:
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.
Filed. Better late than never. :)
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.
Really? Where does it clearly state that? I agree, it seems to make
sense, I just didn't see where the spec is clear on that.
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.
Ahh, ok. A lightbulb just went on over my head. So, the first
instance of a jar found in the list of host and fragments shadows
subsequent instances. The later instance jars never get searched,
e.g. host.jar. So, you are speaking of the "effective" class path
which is created by first merging the host's and fragments' class
paths and then binding the jar path elements to the first jar resource
found.
I hadn't thought of that. I was just focused on the example in
section 3.8.1 where there is no overlap.
So, clearly steps 5 and 6 do not support section 3.8.1 and don't even
begin to address jar resource shadowing in fragments.
Let me ask you this. What if the Bundle-Class-Path was
Bundle-ClassPath: /foo fragment.jar, host.jar
if we found "/foo" in the host path would we *still* also search "/
foo" in the fragments, i.e. "/foo" in host would not shadow "/foo" in
the fragments?
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
