cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: JNet integration
Date Wed, 26 Mar 2008 13:09:53 GMT
Carsten Ziegeler wrote:
> It seems that this topic is even more interesting than the environment 
> abstraction threads we had a while back :)
> Ok, first of all, the sourceresolver is a very cool component and I 
> really like it (and it was also me who started this component years 
> ago :) ). As the java api lacks such kind of an abstraction, its good 
> to have it.

Does it? It seems to me the URLConnection class provides the same level 
of abstraction and functionnality than a Source.

> Other approaches like the Spring resource stuff are not as good as 
> they are not very flexible.
> So, it doesn't make sense to drop this stuff for Cocoon - seeing 
> Cocoon as the "big" framework for building web applications.
> But on the other side we are talking about making Cocoon more modular 
> and easier to understand. The Corona work is a great start and for me 
> it makes totally sense to base the core api just on the java net 
> stuff. It's much easier to understand and use. When we were doing 
> Cocoon trainings, it was always a little bit difficult to get the 
> point across that people should use the source resolver and not the 
> file api or the java net api. Not a big deal, but still it adds more 
> new stuff on top of the core api than you might need.
> While the source resolver, source factory and source interfaces are of 
> great use, I'm not so sure about the extensions of the source 
> interface like modifiable source or traversable source. I rarely 
> needed them through the years, but your mileage might vary.
> Caching is very important and the java api does not provide a very 
> good way to support caching in general. The source abstaction was 
> built with caching in mind.

Hmm... If this is just about Source.getSourceValidity which is 
optionally implemented (non-caching source can simply return null), we 
could equally well have a CachableURLConnection.

> If you look at the pipeline caching we have in cocoon it is rather 
> complicated (it can cache partial pipelines etc.), and during the 
> years we switched for a time based/event based caching of complete 
> pipelines. But again your mileage may vary.
> The question is now if we need support for caching in the low level 
> apis or if it is possible to have a layered approach - which would 
> make the entry barrier much easier.

The main need for the Source abstraction was to circumvent the 
staticness of URLStreamHandlerFactory. Otherwise, pretty much everything 
we need is there:
- extensible framework for cacheable, modifiable, traversable, 
whatever-able sources with URLConnection sub-classes,
- integrated parsing/conversion features with the getContent() method
- source-resolving using the URL(URL context, String spec) constructor

The staticness problems of URLStreamHandlerFactory are still there in 
the JVM, but the OSGi/Equinox guys have found creative ways to 
circumvent them on most JVMs. If we're happy with this solution, it 
seems to me the Source abstraction is one of the many "cocoon-isms" we 
should consider to gently deprecate just as the copy of the servlets 
that we have in our environment abstraction.

Fewer new concepts to learn for newcomers, fewer specific concepts that 
hinder the integration of Cocoon with other environments.

My 0.02 euros (which are worth their $ these days!)


Sylvain Wallez -

View raw message