cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: What does a block need to run?
Date Mon, 23 Jan 2006 18:08:54 GMT
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 

>  - blocks framework


> 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?


> The artifact produced in [2] is used from within the deployer to create 
> a webapp skeleton.



> [1] 

> [2] 

View raw message