Alexander Klimetschek skrev:
Hi Daniel,
I am playing around with the new blocks protocol and the BlockServlets.
Cool!
I have two blocks A and B, B "inherits" from A and then there is a
webapp that uses both blocks. The webapp has the DispatcherServlet
configured in the web.xml and the mountPath for the two blocks is
defined in the spring-bean config XML file. Now I face two problems:
1) I'd like to configure the mountPath to the blocks in the webapp,
because the blocks itself are generic; I have tried it with a
properties file manually placed in WEB-INF/cocoon/properties that sets
the mountPath:
com.domain.package.blockA.mountPath=foo
But this does not work. How can I override the setting in the bean
config XML with a property?
The possibility to override bean properties is very new and I have not
tested it yet, see
http://marc.theaimsgroup.com/?t=116012787900003&r=1&w=2 for a
description of how it is supposed to work. I am not certain that it is
tested yet. Maybe Carsten can say something about it.
For the moment it might be a safer bet to use the property mechanism
that already is part of trunk. Here you need to use parameters like
${com.domain.package.blockA.mountPath} directly in the configuration and
give them a default value in a property file. See e.g.
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/resources/META-INF/legacy/xconf/cocoon-core-store.xconf.
2) The nice development feature of sitemap reloading does not work
when working on blocks, because you cannot deploy a block with it's
own web.xml (that has the necessary DispatcherServlet). I use the
webapp which will use the packaged jars from A and B.
The hurdles here are:
a) the cocoon deployer will overwrite the web.xml with no
DispatcherServlet configured
In the short term we should fix the deployer so that it doesn't remove
the DispatcherServlet. I don't know much about how the deployer works,
could someone who does comment on this?
We have some ideas about how to get rid of the need for the deployer in
the development cycle. See
http://marc.theaimsgroup.com/?t=116013240800001&r=1&w=2,
http://marc.theaimsgroup.com/?t=116034430600002&r=1&w=2 and
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116035392308084&w=2 for
that discussion.
b) the blockContextURL should point to the source-folder (like in the
sitemap generated by the deployer) so that reloading works on the
developer's working directory
Currently the implementation only resolves a path relative to the webapp
context (like for the context: protocol). This should clearly be
generalized to be able to handle other protocols.
c) that blockContextURL must be overwritten by the deployer via a
property (problem like in 1)
See my answer to 1)
I'd imagine a deployer that recognizes the
-Dorg.apache.cocoon.mode=dev and then configures the webapp to work as
above. I could do some work on the deployer plugin if those points are
resolved.
Patches are always welcome.
Another question then arises for the final wiring of blocks: typically
I have a root sitemap and mount my different sub-sitemaps there. But
when each sub-sitemap is now served via a BlockServlet I must have the
DispatcherServlet listening on "/" so that I need a separate
BlockServlet serving the root (like /index.html). It would be very
cool if one could mount a BlockServlet directly inside the root sitemap.
I think there are two main scenarios: You use a ordinary PipelineServlet
for the root sitemap and BlockServlets for the blocks that you use. Or
you let everything including the root sitemap be a block.
To make it easy to start using blocks from existing Cocoon webapps we
should probably make the first alternative easy to use. In that scenario
you typically will mount a SitemapServlet containing the root sitemap at
"/", and the DispatcherServlet at e.g. "/blocks". The block protocol
doesn't work from the root sitemap to the blocks, as the block protocol
is designed for inter block communication and require that blocks are
wired together with Spring. It might work with
"http:/blocks/myBlock/foo", not certain though. I'm thinking about
implementing a "blocks:" protocol for this scenario. It would use the
global bean id for the block instead of the bean local property name.
There was something like that in an early incarnation of the blocks
framework.
For the case when also the main sitemap is in a block, you can just wire
it to the used blocks and use the block: protocol. As long as the block
deployer is required for updating the block, this would be rather
painful. We really need to do something about the deployment.
Thanks for testing the blocks framework and for the feedback.
/Daniel
