Alexander Klimetschek skrev:
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.
Great. The patch looks good, I will apply it.
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
OK
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?
No, we discussed having a configuration file with associations between
block name and block path, that overrides the blocks in the classpath.
By using that you can point to your block under development.
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 ;-)
Hopefully.
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>"?
Exactly
That sounds very cool and should IMHO be part of the blocks-framework
before releasing 2.2.
Agree.
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.
We have built reusable applications on my company, using a much more
primitive mechanism for sitemap inheritance, and it works very well.
That has been the main motivation for me to work on the blocks framework.
/Daniel
