On Mar 31, 2008, at 12:04 AM, Danail Nachev wrote:
You are right that each Bundle-Classpath element should be searched in
the host bundle and attached fragments. This is explained in the
3.8.1.
Steps 5 and 6 are used to explain that the Bundle-Classpath of the
host
bundle is used first and then the Bundle-Classpaths of the attached
fragments.
Your last sentence here is as vague as the two steps and inadequately,
actually inaccurately, describes what really must take place to
support the scenario in section 3.8.1.
I didn't find, however, where it is explained how the Bundle-Classpath
header of the fragment is merged with the host's header, except these
two steps. They can be easily be merged into one, but I don't think we
gain something. It might be good to add explanation to 3.14,
explaining
how the Bundle-Classpath headers are merged, but it isn't essential,
IMHO.
You are correct. It's implied from reading section 3.8.1 and not
explicitly stated. However, I have a different opinion than you.
It's a spec. Everything should be explicit.
Regards,
Alan
BR,
--
Danail Nachev
Senior Software Engineer/Development Tools
ProSyst Labs EOOD
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Alan Cabrera 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. 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.
This means that steps 5 and 6 really need to be merged into a
single step.
Did I misunderstand something?
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
