cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 13:29:12 GMT
Daniel Fagerstrom wrote:

> Sylvain Wallez wrote:
>> Leszek Gawron wrote:
>>> other example that I posted some time ago: if every cocoon uses 
>>> error2html.xsl by default (along with some other default resources) 
>>> they should be also packed into jars.
>> Aha! This is something I wanted to talk about when working on Cocoon 
>> stacktraces: standardizing the fact that some blocks provide 
>> resources and include them in jars.
>> The first block to do this is CForms, which provides a lot of runtime 
>> resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc. 
>> We also have a few items for the core block in 
>> webapp/stylesheets/system and webapp/resources (js and css). What we 
>> see here is that these are runtime resources targeted both at the 
>> server side (XSLs) and the client side (js, css and also XSLs for 
>> xsl-aware browsers).
>> What I propose is that we define a standard layout for resources 
>> provided by blocks: they should be stored in 
>> resource://org/apache/cocoon/{block-name}/resources/
> The nice thing with this propsal is that it is back compatible and 
> follow current (emerging) conventions. OTH with the blocks 
> architecture, using the resource protocol is not such a good idea. In 
> OSGi resources have URLs like bundle://3/ e.g. 
> where "3" is the number of the bundle and is deployment order 
> dependent and is therefore not usable in sitemaps. In OSGi one 
> typically puts the resources at the top level of the jar or in 
> directories at top level. There is normally not that much reason for 
> puting resources in the Java package structure, as the bundle poften 
> is an apropriate level of granularity anyway.

Hmm... as I understand it, the bundle: protocol is similar to what is 
returned by ClassLoader.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).

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.

> 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:"

>> Additionally, we should have a system-defined URI which allows 
>> clients to fetch these resources, implemented in the root sitemap:
>> <map:match pattern="_cocoon_/*/**">
>>  <map:read src="resource://org/apache/cocoon/{1}/resources/{2}"/>
>> </map:match>
>> By standardizing this URI pattern, we can easily solve 
>> cross-referencing problems among resources, e.g. CForms XSLs having 
>> to produce <script src="..."/> to load the JS files, etc.
>> This URI pattern could even be written **_cocoon_/*/** to be 
>> location-independent so that we don't have to mess around with 
>> {request:contextPath}.
> 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?

>> WDYT?
> Your proposal makes sense and we should make something about the 
> issues you describe. What you describe will not be particulary future 
> proof though.

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)?


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message