Upayavira wrote:
Sylvain Wallez wrote:
Hi folks,
In one of our projects, we use CocoonBean in a CocoonServlet environment to dump a collection of generated documents on disk. Doing this, we encountered two problems:
- CocoonComponentManager.checkEnvironment barfs and throws an Exception since the servlet environment exists on the stack when the CocoonBean starts its processing.
Obvious solution is to remove this test, as indicated in the method's comments.
I'm okay with it. Although it would be better if the Bean within a servlet could share the Cocoon object, along with all that goes with it. That would make the Bean really quick to start up. I believe Unico had ideas about this.
If the CLI and Servlet environments were sharing the same Cocoon object, the CLI wouldn't load a logkit.xconf and there would therefore be no problem.
But in my particular case, it's better for the two environments not to share the same Cocoon object, as this allows to cleanly separate the application front end (the CocoonServlet) from the publishing part (the CocoonBean).
Does this mean that you have two webapps? I guess my ideal would be one bean per webapp. Is that what you mean by "clean separation"?
What do you do about the slow startup of the bean? It needs to initialise an entire Cocoon instance before it can do anything. Do you run the bean in the background, or keep a app context bean? Would it help if the bean was known to work in multithreaded environments?
Regards, Upayavira
Sylvain
