I note from commit messages that Berin has completely changed the purpose of the CocoonBean. The CocoonBean is a published (if not entirely stable) interface, and therefore I think this needs some discussion before it can be changed significantly.
It seems to me that Berin is trying to create a bean to have a clean access to the Cocoon class, which seems fair enough - I've got no objection to that.
What I am doing is taking the purpose of the CocoonBean, and making it more clear. Proper separation of concerns, adding functionality in la
However, it is a completely different thing to the current bean, which is much more geared around offering a non-Avalon interface to Cocoon for inclusion in other java code.
Actually, it is not too far different from the current bean. First, it is more truly a bean. Setters AND getters for every configuration option. Secondly, it is split into three different beans, each extending the other. The first bean is purely the clean access to setting up the core options for the Cocon environment with the ability to start and stop the system.
On top of that, we have a ProcessingBean (if my memory serves me for the actual use of the system). That processing bean takes care of processing a request or compiling the generated classes in the system. Lastly, we have the BatchProcessingBean which is more like the previous CocoonBean. The BatchProcessingBean provides the support to run a number of URIs through the system, which is what you are probably referring to.
The old CocoonBean comes short in this respect because it assumes that everything will do batch processing. That is not true. For example, the Servlet environment does not do that. It might use the ProcessingBean, or it might use the new CocoonBEan only.
I think it is important when we write things along those lines that we make no assumptions for any particular environment--and we provide extra functionality with subclasses as necessary.
I think that the CocoonBean should be left in its place, and that Berin's bean should be placed somewhere else (and named suitably so as not to cause user confusion when people go hunting for the CocoonBean).
What do others think?
:/ I think we should just have ONE bean that can work in any environment, including the Servlet environment (which the older bean did not do very well). Having two beans would lead to confusion.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin