cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [Kernel2.2] Source Resolving
Date Wed, 31 Mar 2004 12:51:17 GMT
On 31 Mar 2004, at 13:25, Carsten Ziegeler wrote:
> Pier Fumagalli wrote:
>> I don't think there are going to be more, as blocks libraries
>> themselves can be represented as a directory (File) and a JAR
>> archive (JarFile)... So, for resolution of sources _between_
>> block, nothing else should get in the way...
> Hmm, what if Cocoon is deployed as a war file and the servlet
> container doesn't unpack the war to the file system?

Uh, careful... Libraries provide resources AND classes.

The servlet container provides a single monolithic classloader, so, at 
the end it would be insufficent for class loading.

In those environments, I'd think that we should expand each block 
contained in the WAR into the temporary directory exposed by the 
servlet container, and base all blocks loading from there.

I'm thinking that blocks should always be distributed as "zip" files 
(note, not JAR archives), containing a "block.xml" file (block 
descriptor) and the different JARs required by it (its libraries) or 
its directories...

This zip should be expanded by a Library implementation so that a 
Loader can instantiate a Block, and this expansion can (should) be done 
in the temp directory...

>> If we want to build the full resolver inside the framework
>> itself, and therefore the "resolve" method in "Wirings" and
>> "Wire" will accept "block:wiring:/path" instead of only
>> "wiring:/path", then yes, I agree with you that source
>> resolution should be closer (or same as) Excalibur's SourceResolver.
> Currently, I don't know which way is better :) Perhaps I have to
> understand the whole thing before I should comment on just some
> parts...

In my requirement for the framework as VNU I don't personally need the 
"extended" (a-la SourceResolver) resolution, but it's trivial to 
implement, although it poses some questions on how to implement it... 
I'll leave this up to you guys to decide what's better...

>> Only "issue" I might see with that is that Excalibur's Source
>> doesn't have the "isDirectory()" and "children()" methods,
>> so, well, I don't absolutely like it because it's prone to hacks.
> Ah, this is in a sub interface of Source (TraversableSource or 
> something
> like that).

On 31 Mar 2004, at 13:09, Gianugo Rabellino wrote:

> Uh? It's in TraversableSource, a subinterface, yes, but it's there...

I still prefer something like:

if (!source.isDirectory()) throw Exception("I need a directory");

rather than

if (!(source instanceof TraversableSource)) throw Exception("I need a 

I don't see the point of two interfaces (and as I did, it's easy to 


View raw message