Daniel Fagerstrom skrev:
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
...
Of course we need to create the container somewhere. But that code
should be isolated, we should really avoid having dependencies on
heavy weight containers all other the place.
I absolutely agree; I think we should move the container code out of the
tree processor, so the tree processor is just for processing the
pipelines and parsing *that* part of the sitemap. The container code
will also read the sitemap, but only the components part. This requires
to read the sitemap twice, but cleans up the concerns. WDYT?
Agree. One possibility would be to make a component of the
SitemapLanguage.createApplicationContext method (except maybe for the
listener setup in the end). It could be BeanFactoryAware and LogEnabled,
and have the createApplicationContext method as its API. AFAICS it would
only be needed to be created if the sitemap actually contain a
configuration element. Which would make the treeprocessor container
dependent only when it needs internaly configured components.
I made a hack that means that the sitemap local bean factory only is
setup when there actually is a sitemap local component configuration.
This means that the still ECM dependent blocks fw work with limited
functionality again. The test cases without sitemap internal components
succeeds.
It should be possible to continue the work on the blocks deployer.
I will of course work on switching the blocks fw to the new container,
but now we can focus on getting the new contaner stable first.
/Daniel
