Reinhard Poetz skrev:
Yesterday I worked again on the cocoon:simple-deploy Maven goal which
can be used to deploy a project that contains a Cocoon block. It runs
through now for a very simple block[1] but it doesn't create a valid
Cocoon web application yet. And that leads to my question now:
If we think of the simplest possible block, what do we want that it
depends on?
The simplest possible block that generate content is a hand written
Servlet together with a block.xml. So it depends on the Servlet API.
A block containing components depend on the component container class
(the choice of which is configurable) and on the API for pluging in the
container which right now is the Avalon Framework API, but could change
to something else if we want it to.
A logger interface is also needed.
The usual block has the basic requirement of some core components (file
generator, trax transformer, xml/html serializer, ...). In order to get
blocks run, it additionally has (indirect) requirements of
A sitemap servlet based block would depend on that. I would not like to
introduce any default dependencies, as many of us believe that a
flowscript, javaflow or even a RoR inspired controller would make more
sense as a top level controller in the future.
For the pipeline components we would like to be able to use pull
pipelines as well.
- an environemt
Our environments only make sense for sitemaps, for general servlets the
http servlet interfaces with some utility classes are enough.
I would like to make our environment abstraction interfaces extend the
http servlet counterparts. Also the CLI should be considered as a
special purpose servlet container that the blocks manager can be
executed from rather than connecting to Cocoon at the Processor level as
today.
- blocks framework
Yes.
Is there something else?
Not right now. but when we have made the core more layered there will
typically be more fine grained dependencies.
According to the pom.xml of the blocks framework, it depends on
cocoon-core. I'm not sure but if we consider cocoon-core being a block
too, we get a circular dependency, don't we?
Yes it becomes circular, OTH I don't want any special purpose component
configurations during the bootstrap of the blocks system. The workaround
for now should IMO be to have cocoon-core at the initial classpath
(WEB-INF/lib) and have a fake core block that only contains the
configuration file, but no classes.
I'm working on making the block FW independent of core, but I'm not
finished yet. It might not be possible until we have started to split core.
The SitemapServlet, the ECMBlockServiceManager, the block source and the
block attributes, and some of the utility classes should be moved to
separate block and are not part of the block framework but rather
components that can be used from it and in relation to it.
Coming back to my initial question, I think that a block should only
have a dependency on some kind of core block. This core block contains
the most basic sitemap components and has dependencies on
- the environment (HTTP environment as default)
- the blocks framework (Daniel's current implementation as default,
OSGi could
be another implementation)
- more core stuff (sitemap, pipelines, caching, utilities --> needs to
be split
up later)
Daniel (and others), is this they way we want to go or do you envision
something different?
See above, in practice however it will be as you describe in the first
step as we only have a sitemap controller and ECM++ block service
manager yet. But from the considerations above I want explicit
dependencies rather than some automatic default inclusion of everything.
A final question: Do we have something that could be called "runtime
environment"? For now I can only think of the web.xml if you use Cocoon
from within a servlet container[2]. Right?
Yes.
The artifact produced in [2] is used from within the deployer to create
a webapp skeleton.
Ok
/Daniel
[1]
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-plugins/cocoon-deployer-plugin-demo/README.txt
[2]
http://svn.apache.org/repos/asf/cocoon/trunk/cocoon-plugins/cocoon-minimal-webapp/
