Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
Filled up an issue: https://issues.apache.org/jira/browse/COCOON-2176
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
java.net.URL 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
java.net.URL 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.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
