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