cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: SourceResolver in SSF
Date Mon, 17 Mar 2008 17:21:14 GMT
Grzegorz Kossakowski wrote:
> Carsten Ziegeler pisze:
>>> Filled up an issue:
>>> My plan is to register default Excalibur's SourceResolver 
>>> implementation as a Spring-bean and use it by default. Then, Cocoon 
>>> Core would replace it with CocoonSourceResolver using Spring 
>>> configurator features (property overriding, etc.).
>> Not sure if it helps you, but can't we change the SSF to just rely on 
>> and use excaliburs jnet underneath?
> I don't know JNet and new solutions for source resolving so cannot 
> comment. Any pointers to documentation or discussions?
So far there is only the source code :(

Ok, we planned to do this step in Cocoon for years: just using plain objects to get access the different sources.
Now, unfortunately even today, Sun has not provided a usable api to 
register own url handlers. So this is the main challenge as you can only 
register a url handler once for the whole jvm. And as some application 
containers register their own url handler on startup, a webapp can't do 
this anymore. Not to mention the problem when you have more than one 
webapp trying to do this.

However, there is a trick (or call it hack) to circumvent this problem 
by using reflection and registering a proxy which then forwards to the 
appropriate url handler. Jnet has an implementation for this and is able 
to forward it to excalibur's source resolver or more precisely directly 
to the source factories. Now to work propertly for each request jnet 
needs to be notified which source factories are available and when the 
request is finished, this needs to be cleared. So it basically like the 
context change we use in cocoon.

Then you can do something like URL u = new URL("cocoon:/mypipeline");
u.getInputStream(); // or similar

Of course, when it comes to XML getting an input stream is not the best 
choice, therefore there is an additional handling, so you can call
u.getContent(SAXResult.class) returning a SAXResult (from the javax.xml 
Using this you have direct streaming of sax events (if the source 
provides it) without using any additional interfaces.

Now, this comes with one problem: the hack to register the url handler 
proxy might not work on all jvms, it should work on all Sun jvms and 
getting it running on Harmony shouldn't be a problem. I think its 
running on ibms jvm as well, but i'm not sure.

So, this is the rough idea - the implementation is a first prototype I 
did last year, so there might be some rough edges.

If this code is of interest we could also move it to Cocoon to have 
better control.

Carsten Ziegeler

View raw message