cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Date Mon, 03 Nov 2003 21:33:19 GMT
Sylvain Wallez wrote:

> 
> Sure I will. It would clearly be a bad thing to trash the time and 
> effort Bering has put there. I may not have the required time to do it 
> by myself, but I'm ready to answer questions. So maybe with the combined 
> support of Berin and me we can turn this into a deeper knowledge of the 
> sitemap engine for the whole group.
> 
> Berin, what's the major wall you hit in the TreeProcessor? AFAIU, 
> Recomposable is a problem, but also something we can easily remove from 
> the code with some light refactoring.
> 
> What are the other difficult points?

The TreeProcessor has a bunch of psuedo-components that are managed differently
than the regular container.  If these were all "threadsafe" components, there
would be less of an issue here.

We should either make them regular components, and provide "configuration"
snippets, or make them beans and provide the full configuration.  THe problem
areas might be where we need to access a component.  For those, we might need
to use a "Component Proxy" that gets the type of component we are looking for
from a typed interface like this:

SitemapComponentProxy {
     Generator getGenerator(String type);
     Transformer getTransformer(String type);
     Serializer getSerializer(String type);
     Reader getReader(String type);
     Action getAction(String type);//NOTE: sets can simply be a
                                   //special action type with the same interface.
}

Anyhoo, the basic solution is to either build a tree/graph of pure components
or a tree/graph of pure beans.  Either solution will work.  We need to get rid
of the need for the LifecycleHelper type class.  I would lean more toward the
bean approach for assembling the actual pipelines.  It might make things a bit
simpler, even to make custom hard-coded sitemaps.

Also, another thing that will emmensely help the issues with RequestLifecycle
components is to refactor it so that there is an Environment.done() or .close()
method that signals the end of processing so that any request-based components
are released as is.

A very nice solution is to add a set of Commands to a "CommandQueue" that is
attached to the Request.  The customized fortress container will then add the
release command to the request as needed.  When the whole request is done, the
system will add all the commands to the central command queue so that it is
processed in the background.  This solution will also allow you to add some
other clean up commands as needed.

The Servlet and Main systems would need to be modified to always close() the
environment to make that happen.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message