Carsten Ziegeler skrev:
Daniel Fagerstrom schrieb:
For your questions about creating Core and Settings I use a
o.a.c.servlet.CoreUtil from cocoon-core that has reduced functionality
and flexibility compared to the ordinary one, it just use the servlet
config as input. It is used within the ECMBlocksServiceManager.
Ok, can we try to use the same code (= same CoreUtil); I think this
would avoid duplicate efforts. I cleaned up the core CoreUtil a little
bit and the BootstrapEnvironment interface got a lot smaller; I think I
can get away with most of the other methods there as well, leaving just
some configuration hooks. And this would then make the
BootstrapEnvironment optional. So you could just invoke the CoreUtil
with a o.a.c.environment.Context object (which inherits from
ServletContext). Would this work for you?
It would work for me.
The reason that I used an own refactored and simplified version of the
CoreUtil was that I had a number of requirements that I didn't see how
to fulfill in the original one without risking to affect the rest of Cocoon.
* I wanted to get rid of the complications with several environments by
just using a servlet context. - No problem anymore.
* I needed to get rid of the state fullness. Before the CoreUtil kept
some state so that it wasn't enough to use it on setup, it was to be
kept and used later. I see that you have removed most of that, the only
essential part remaining is the processor reloading. And I don't need to
use that so it doesn't hurt.
* I needed to be able to create Core, Settings and Avalon Context one at
a time, due to various life cycle issues in the block architecture and
component manager bridge. This is the only remaining issue. But it
shouldn't be that hard impose the same structure of the original
CoreUtil as I did in the servlet.CoreUtil. I think that such a change
make the code easier to follow as well.
/Daniel
