cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: SourceResolver in SSF
Date Mon, 17 Mar 2008 22:21:16 GMT
Carsten Ziegeler pisze:
> 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 
> package)
> 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.

Thanks Carsten for a summary!
To be honest, I'm not sure what kind of action we should take here. What you described sounds
and it's very tempting to have sources properly working with just standard URL class.

Anyway, I'm little bit worried that whole things bases on *ugly* hack. I'm wondering how reliable

the solution is. I have a few additional questions:
1. Has this technique (not necessarily JNet's implementation) been used in some project? Or
your brilliant invention? :-)
2. What about debugging? What about stracktraces? Won't reflection hack break something?
3. How intrusive it would be to integrate JNet into SSF?

I'm interested in experimenting with your work but since this issue is rather urgent I would
like to 
be able to count on your help if it's me who is going to resolve this problem.

What do others think?

PS. Here we are talking about SSF only at the moment. Inside SitemapServlet the CocoonSourceResolver

will be preserved, at least for now.

Grzegorz Kossakowski

View raw message