Hi,
thanks for your answer! Things are really getting better now, as I got
reloading to work (https://issues.apache.org/jira/browse/COCOON-1934) as
written in the other mail.
Daniel Fagerstrom schrieb:
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.
I got it working when I placed the properties file in my webapp-module
under WEB-INF/cocoon/spring and naming the property
<bean-id>/<param>=<value>
so for example:
com.domain.package.blockA/mountPath=/foo
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.
That would indeed be very nice. But how does the reloading work then?
Deploy a special jar into cocoon/libs that somehow points to its
original source folders?
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.
Will see if I modify the deployer for that case. My manual solution (see
the JIRA issue) works so far, so this might happen later. Maybe someone
has changed the way of deploying by then ;-)
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.
Does this mean I could mount a BlockServlet inside a sitemap via
map:mount src="blocks:<global-bean-id>"? That sounds very cool and
should IMHO be part of the blocks-framework before releasing 2.2.
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.
Reloading does work now with my patch, so I'll try that! No more
SitemapServlet inside the web.xml configuration ;-)
Thanks for testing the blocks framework and for the feedback.
Well, I really like the inheriting feature because it allows you to
extract general stuff out of your sitemap into an "abstract" super
block. And we got a case where we need that. If you put together
components in Cocoon and actually program in sitemaps, you have to be
able to separate stuff and let sitemaps itself stand as new components -
which is what blocks now provide.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
