Niclas Hedhman wrote:
On Wednesday 17 August 2005 22:09, Daniel Fagerstrom wrote:
And BTW, unless I missed something I haven't seen an explicit
reference to the "bundle:" protocol in the OSGi specs, at least in R3.
Didn't found it either, maybe it is Knopflerfish specific. But even if
it is, the OSGi api have no direct ways for accessing a resource from
any bundle, you must specify from what bundle you want to read a
resource. Maybe there is a way to do it in some more indirect way.
It is probably a protocol available to be 'installed' at your own leisure
(i.e. the core beauty of OSGi). I have not bothered with it.
Don't know, but I would assume that all OSGi implementation would need
something like the bundle: protocol (although the name and syntax might
not be standardized). Say that you have two bundles A and B that both
contain the resource "foo.xml". If you use "URL getResource(String)" at
the Bundle object of the A bundle the resulting URL must contain a
reference to the A bundle to not confuse it with "foo.xml" from the B
bundle.
Since a protocol is a Service, I assume that the ServiceFactory mechanism
would also work, in which case a protocol could "extract" context information
from the "requesting bundle" and use that to tailor the resulting connection,
including retrieving resources from with that client bundle.
I have not tested this for URLs but using something along those line in a
Log4J bundle, where the "default config" for a bundle is retrieved from the
requesting bundle.
Ok.
I think quite a fair bit in Cocoon should use URLs and custom protocols, and
implement those through the OSGi URL service mechanism.
Yes, that would remove the need to depend on the Source interface in
blocks and make it possible to use external libraries that requires
java.net.URL.
/Daniel
