cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Defining Source Interfaces
Date Mon, 06 Jan 2003 17:23:41 GMT
Stephan Michels wrote:

>On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
>>>>I added before christmas the possibility to retrieve children
>>>>of a source to the Source interface in excalibur and started
>>>>with the ModifiableSource interface (= WriteableSource).
>>>>What else do we need? I think we have a buch of extensions
>>>>to the Source interface.
>>>Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
>>>TraversableSource, VersionableSource, LockableSource, etc.
>>>While working on sources recently (the CVSSource I'm about to publish),
>>>I found the current definition of TraversableSource not intuitive, and
>>>modified it so it's more like to :
>>>public interface TraversableSource extends Source {
>>>    /** Is the source a directory or a collection ? */
>>>    public boolean isSourceCollection() throws ProcessingException,
>>>    /** Returns the collection of child sources. */
>>>    public Collection getChildren() throws ProcessingException,
>>>    /** Returns the local name of this source */
>>>    public String getName() throws ProcessingException, IOException;
>getLocalId() ??? because of getSystemId()?

Look at : you have getPath() and getName(), not getLocalPath().

>>>    /** Return the parent source. Returns null if the source hasn't a
>>>parent. */
>>>    public Source getParentSource() throws ProcessingException,
>I don't return Sources, because Sources can be Components, which
>must be resolved/released by the SourceResolver.
>So I think returning the URI instead of the Sources is a must-have.

I disagree : the SourceResolver is used to get a Source from its URL, 
but a Source is not a component : the component is the SourceFactory 
that creates Source instances. A source itself is not managed by a 

Also, having to hop through the SourceResolver to get parents or 
children of a Source *really hits performance*, as each call to 
resolve() looks up/releases the factory, asks it to create the source, 
etc, etc.

Looking at all traversable sources I know of (Slide source and my 
yet-unpublished CVSSource and TraversableFileSource), getting the 
children or parents Source objects is really trivial and lightweight 
compared to the processing required if we go through the SourceResolver.

Furthermore, I'm really wondering now if we need to release() a Source, 
as I can't find any implementation that actually does something of it.

And I don't think an implementation will ever use it : the point where 
something has to be released in Sources is related to stream methods 
(look at BlobSource.getInputStream()). Also, these methods can be called 
several times during the lifetime of the Source object, and their result 
can last longer than the Source object's lifetime (look at 

And releasing a Source involves once more a look up/release of the 
SourceFactory to actually do nothing...

So, considering that the SourceResolver is one of the most used 
components, removing release() from this interface may lead to a 
significant performance increase.

>>>Carsten, I also some remarks/questions about your changes in Excalibur :
>>>- should parent/child traversal be defined on Source. IMO, a Source
>>>should be kept very simple and basic as not all sources are traversable,
>>Yes, that is true. But always doing an instanceof is not the best advice
>>for doing OOP. So, I thought of adding the most common methods to the base
>>interface and only use extending interfaces if required.
>I like Avalon because of the separation of the contracts. If you implement
>a component, you don't have to implement all lifecycle methods like
>EJBs. If you implement a source you only need to implement the IFs that
>you need.

Yep. The beauty of Avalon comes from it's "Zen-itude" : each interface 
provides the minimal but sufficient set of methods.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

To unsubscribe, e-mail:
For additional commands, email:

View raw message