forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Witeboard Forrest2 committed
Date Sat, 18 Nov 2006 11:14:48 GMT
Tim Williams wrote:
> On 11/17/06, Ross Gardler <> 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 

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

   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).


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 

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 

> 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.


View raw message