Tim Williams wrote:
On 11/17/06, Ross Gardler <[EMAIL PROTECTED]> wrote:
...
Where's the servlet exposure?
It's not part of core it is a separate module in order to keep core size
to a minimum. The objective is to make it as embeddable as possible.
I have a webapp module, but have not committed it yet (got to do the
licenses).
It's a good illustration of how simple it is to embed though, there is a
single servlet controller with:
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException
response.setContentType("text/html");
PrintWriter out = response.getWriter();
URI requestURI;
try {
requestURI = new URI(request.getContextPath());
AbstractOutputDocument doc;
try {
doc = controller.getOutputDocument(requestURI);
} catch (
// removed for brevity
}
}
Where's the pipeline defined?
In the forrestContext.xml. It is described in each of the overview, the
readme and the examples (but that doesn't mean you will understand it
since only a couple of people have read it).
Briefly:
All pipelines are Reader -> Input Plugin -> Output Plugin
Readers are selected based on the protocol in the source URL (retrieved
form the locationmap). The protocol corresponds to the bean id in
forrestContext.xml.
So a source of "file://foo/bar.xml" will use the reader identified by
<bean id="file"...> in forrestcontext.xml
The reader produces a document encapsulated in a class that exposes a
getType() method. Whatever that method returns is used to select the
input plugin to use. Again selected on the bean id in forrestContext.xml
The output plugin is selected slightly differently. This is because each
output plugin may be used for many request URI's. What happens is the
client request URI is matched against a pattern property that is defined
in the output plugin bean in forrestContext.xml. The pattern is a
regular expression.
Hopefully this will help you read the examples included in the
contribution. (I'll add this to the documentation as well)
Are
producers and consumers throughout the pipeline dealing with Strings
instead of SAX events?
At present yes, but that is not the end goal. SAX events are where it is
at, of course.
Have you already explained to us an analysis
of String vs. SAX vs. STAX while I wasn't paying close attention?
No, when we discussed it I agreed we need to use streamed events not
strings. It was just quicker and easier to pass strings about in this
prototype.
Once I understand it, I promise to provide more substantive
feedback/contributions; until then, the core and src main directories
have counter-intuitive content for me at least.
Not sure what you mean by this. If you mean the directory structure is
confusin then you are most likely correct. I originally had a single
module with all the plugins and modules in the same directory, hence I
had core, readers, inputPlugins, outputPlugins and extensions all in the
same module.
I've now stripped those out and we are therefor left with just core.
I'll tidy up further at some point.
Thanks for taking the time to contribute this stuff, I suspect it'll
be a foundation for some fruitful discussion.
Cool, that's the goal - thanks for your initial feedback and encouragement.
Ross
