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()
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. 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).
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.
We also have the block protocol that allows you to define what block
the resource is taken from: block:foo:/bar.xsl. Now the block
protocol assumes that everything is exported through the sitemap
wich might be appropriate (but maybe inconvenient) for the use cases
you have in mind. Maybe we could have an own bundle protocol
(through the source mechanism), that works like the OSGi bundle
protocol but have symbolic block names instead of bundle numbers.
Something like "block-resource://org.apache.cocoon.forms/..." ?
This can be implemented today in 2.1.x by having this protocol
delegating to "resource:"
That would be one possibility, question is if we want direct access to
blocks. Part of the idea with blocks is to have symbiolic names for
the blocks so that one can chnage implementation. OTH a package name
could be seen as a symbolic name as well, so it might be good enough.
Right. In this case, I consider these resources as well-known things and
placing them in jars is a way to allow them to have well-known names and
avoid to copy them around each time we start a project. In this regard,
the resource name is similar to a class name: classes don't move around ;-)
So this is really about accessing a resource more than a service, which
is what block bring us. Sure, the distinction is somewhat subtle. We may
want in the future to implement access to these resources as block
services, the Forms block implementing this service as an access to the
resource. In the meantime, we can consider the access through
"resource:" as an transition step between copy/paste in each application
and block-powered services.
<snip/>
All this is allready solved within the (sitemap) block architecture
and there is an implementation of it in trunk. block URIs are used
for accessing things and a special URL rewriting transformer
absolutizes the block URLs.
I'm proposing here a public URL pattern that can be accessed by
browsers. Block URIs are an internal thing and this pattern must be
implemented somewhere, no?
The idea for blocks is that blocks that contain public URLs are
mounted at deploy time at a some root URL, then the URL revriting
transformer translates internal use of symbolic block names to the
public exported ones.
Ah yes. So for now in 2.1.x, that rewriting stuff would be the little
sitemap snippet I proposed.
<snip/>
So how do we make it future proof yet possible in 2.1.x? Can we have
a single naming scheme (with a new protocol) implemented differently
or pointing to different locations (the 'resources' dir can be
located at the top-level of a bundle)?
Something like the block-resource: protocol could work. As said above
the question is if we want direct block references, the block
architecture only allow direct block refernces in the deploy
descriptor and use symbolic names everywhere else.
For where to put the resouces, we could put them in a "resources"
directory at top level and then let the build process put it at the
place appropriate for 2.1.x and OSGi based blocks repsectively.
Another question is of course if we really should back port everything
to 2.1.x.
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
