cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 14:53:42 GMT
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


Mime
View raw message