cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 14:09:59 GMT
Sylvain Wallez wrote:

> 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/org.apache.cocoon.foo 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(),

It will be returned by getResource() in Knopflerfish.

> 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.

>> 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.

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

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.

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

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.

/Daniel


Mime
View raw message