Giacomo Pati wrote:
<snip/>
In Reinhards document it is META-INF/block.xml on the Wiki it's
COB-INF/block.xml. So we need to make a decision:-)
Please use META-INF/block.xml, AFAIK we agreed on making our blocks valid JAR
files. The skeleton in my tutorial should be compiled and packaged to an archive
having following content:
/JAR-FILE-ROOT
+-com
| +-mycompany
| +-blocks
| +-myblock
| +-MyCocoonAction.class
+-META-INF
| +-block.xml
| +-com
| +-mycompany
| +-blocks
| +-myblock
| +-pom.xml
+-cocoon-app
+-sitemap.xmap
+-test.xml
If we follow the default Maven directory structure as outlined in my tutorial,
the archive will be created automatically for us.
Now to answer your question ;) the position of the .xconf of a block
is defined in the components element of block.xml.
Ok, looking at [1] it is defined in the block.xconf file, which is
located in COB-INF (or WEB-INF or META-INF respectively). Is that still
correct?
I'm not sure where block.xconf should go to. I'd put it under cocoon-app and not
under META-INF. WDOT?
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.
Forget it. The current inclusion mechanism with the xconf directory in
WEB-INF is obsolete I guess.
yes
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?
I'd pretty much like distributed logging configuration (whereas
distributed logging implementation might be overkill).
I want to see this too. But I think we should wait a bit with finding solutions
for this.
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.
One thing of the web.xml is configuration stuff that is passed to the
Servlet (which is Cocoon) deployed. This is not troubling me (we do have
other mechanisms to pass down configuration values as you've described).
The other thing is container configuration as defined by the Servlet
Spec (security, mime types, and alike). Blocks might want to define
security policies for the URL they are mounted on.
good points, but same again here: we should wait until we have a simple block
based application running and then we can talk about this, logging configuration
and settings/property management.
[1] http://wiki.apache.org/cocoon/BlocksDefinition
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
