Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)

[Sylvain Wallez <sy...@apache.org>]

Berin Loritsch wrote:

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

Thanks for continuing the discussion, Berin.

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


Processing nodes are organized in a tree and need to have some features 
devoted to components such as accessing the CM/SM or needing to perform 
some cleanup and thus being disposable.

This led to the current architecture since I considered that components 
could only be have a flat organisation. Now maybe I was wrong, and would 
like to know how we can build a clean tree of components (we're likely 
to need this in Woody as well).

I'll be out of office tomorrow and it's currently late here (11:30pm), 
but I will continue this thread as soon as time permits.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com