Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Hmm... as I understand it, the bundle: protocol is similar to what is
returned by ClassLoader.getResource(),
It will be returned by getResource() in Knopflerfish.
What getResource()? There are plenty of them ;-) I guess it's
Bundle.getResource()
In this case I meant the getResource from the class loader of the bundle
http://www.knopflerfish.org/programming.html#dataaccess. But the same
things holds for Bundle.getResource().
and is abstracted by the resource: protocol implementation (it can
actually be a jar: or a file: or something else that we never see).
Yes.
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.
Yes, they do have access to resources in a bundle *if* these resources
are packaged in the bundle's classpath and declared in the exported
packages.
If you use Bundle.getResource you actually have access to everything
from the class loader of the bundle you got the Bundle object from. See
4.23.3.11 in the R3 spec. I used this for the implementation in trunk to
be able to access the content of the webapp bundle. Take a look at the
Activator for the osgi-servlet bundle.
> Loading resources in jars follows the exact same path as
> loading classes (that what I understood from the spec and verified in
> the Oscar/Felix implementation).
This is the case if you use the classloader of the current bundle for
loading the resources rather than Bundle.getResource.
So the "resource:" protocol will behave with OSGi just as it behaves
otherwise, with the restriction that the search path is restricted to
the bundle's dependencies.
Yes, as it will use the classloader of the current bundle. This will be
somewhat inconvenient in the current OSGi based implementation where the
webapp block (or a user defined webapp block) is "passive", i.e. doesn't
have an own Activator. All classloading is done from the cocoon core
bundle that therefore need to import all packages that the user could
want to use for resource loading. This can be done by doing a:
DynamicImport-Package: *
but this can lead to unexpected consequences as external packages takes
predence to internal ones (4.4.5 in the spec).
By just having this possibility for o.a.c packages as we have right now
in the cocoon core bundle (for being able to do some experiments with
non service based component import), might be a reasonable compromise.
<snip/>
For now I'm concentrating on a 2.1.x issue, which of course should work
on 2.2 even if 2.2 provides more advanced and powerful features.
I just wanted to bring to the table that we allready have a more
convenient solution in 2.2. But if you need it right now in 2.1.x, just
go ahead with your original proposal. We can probably make it work in
the OSGi based architecture as well as indicated above. And then we can
later provide the more convenient block: protocol based way of handling
the resources. Trying to find a way to back port part of the block stuff
to 2.1.x before we even have start to get any experience about it in 2.2
will just complicate things.
/Daniel
