cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Block deployment: working with blocks from a user's point of view
Date Thu, 12 Jan 2006 20:44:29 GMT
Giacomo Pati skrev:
...
> Where should .xconf file be located so they will be included?

There is a working example of the blocks architecture that runs under
servletunit (and soon under Jetty) at
cocoon-blocks-fw/src/test/resources/org/apache/cocoon/blocks

It is not yet adapted to Reinhards latest naming and directory
structure, but most things are the same. The only configuration file
with predifined position is wiring.xml at the servlet context root 
(/WEB-INF/wiring.xml in Reinhards
document IIUC). The wiring.xml can give
expilcit locations for the blocks, otherwise they have the default
location /WEB-INF/blocks/.

In each block there is a block desciptor located at /COB-INF/block.xml 
relative to the block context root (which was given in wiring.xml or by 
default).

As a side note I would prefer to use /WEB-INF/block.xml instead as the 
container for a single block, (after the ongoing refactoring) will be 
servlet that can be run independently as long as it not connects to 
other blocks.

Now to answer your question ;) the position of the .xconf of a block is 
defined in the components element of block.xml.

> Do we need a different mechanism to include those (is copying over to 
> the Cocoon WEB-INF/xconf an option for rapid development)?

For blocks the component configuration file is intended to be fixed and 
included in the block jar. So it is never copied anywhere as in 2.2 
before M2. User configurability is solved with using block properties in 
the configuration file instead. Whether this will be enough is an open 
question. But I guess most agree with that the copy and modify approach 
to configurations in 2.1 not is the way to go.

For rapid development the wiring.xml (or some development time 
equivalent) should point to the source code of the respective blocks, 
rather than on some packaged and deployed blocks.

> How can one ev. define logkit.xml stuff if they want to have their own 
> logging factory/target/category for the components defined in the block 
> (asuming logkit is still the main logging system in Cocoon)?

That is an open question, we have not discussed that much. In the 
current implementation I have just reused the existing Cocoon mechanism 
with centralized log configurations in /WEB-INF, and is feeding the 
Logger to all the blocks. But I would much prefer to distribute 
configurations and maybe even choice of logging framework to the 
individual blocks. OTH completely distributed logging with numerous log 
strategies in the same applications, will be nightmare when trying to 
see what got wrong so some level of centralization is required.

WDYT?

> Same applies to stuff going into web.xmlof the context?

After the refactoring I actually use the ServletContext, with a few 
extra methods for all block context information and inter block 
communication. Everything isn't implemented yet, but the idea is that 
the individual blocks get a context object that wrapps the servlet 
context from the container and in some cases add and in some cases 
overide the content of that.

But this is also a rather open question. The current implementation uses 
the o.a.c.core.Settings interface that Carsten have developed and that 
have a rather neat impelemntation where you can combine the web.xml 
parameters with Java properties. But the bad thing about it in the block 
context is that it is centralized. We need to discuss what settings that 
need to be centralized and what we want to handle on the block level.

/Daniel

Mime
View raw message