Niclas Hedhman wrote:
On Thursday 18 August 2005 05:08, Daniel Fagerstrom wrote:
Is there more to it??
That an OSGi framework need to have a protocol like the bundle protocol
as part of its implementation to be able to implement Bundle.getResource
as motivated in my example above.
I guess it is not important, but I am not sure I follow what you mean.
For the subject it is rather OT, but the discussion have clarified some
technical details about OSGi for me at least. What I meant will
hiopefully be clearer later in this mail.
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.
Why can't it return
"jar:file:///home/niclas/.oscar/cocoon/bundle4/version0.0/bundle.jar!/foo.xml"
??
It can if the installed bundles happen to be deployed in such a form. In
Knopflerfish bundles can either be deployed in memory or at the file
system, which mean that it must contain a protocol that know about the
local bundle instalation structure.
AFAICT, the specification (R3) does not require the returned URL to be
globally resolvable,
If you mean globally resolvable within the current OSGi instance I
interpret 4.23.3.11 in the spec as that the returned URL should be
resolvable in any bundle that has the right AdminPermission.
and bundle://4/foo.xml is also only resolvable in the
current OSGi instance, not even the within the same JVM.
Probably, although the URL registration mechanism in Java is rather
hacky and have some "register only once" semantics that might make the
bundle protocol more global than one want to.
--- o0o ---
Anyway, Sylvain's original proposal will solve the problem he want to
solve and will probably be possble to get to work under OSGi in 2.2. And
that proposal will use the classloader of the calling object rather than
the more flexible Bundle.getResource mechanism. Which makes our current
discussion somewhat OT.
/Daniel
