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...
Ah, this is in a sub interface of Source (TraversableSource or somethingOnly "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.
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 directory");
I don't see the point of two interfaces (and as I did, it's easy to miss).
Pier
smime.p7s
Description: S/MIME cryptographic signature
