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
