IIUC the only component in Cocoon that knows about blocks is the BlockManager. It gets its information from wiring.xml (read only for the BlockManager) and a "watchdog" notices changes and notifies the BlockManager that it has to (re)load blocks.


The "component" which is responsible for changing this wiring.xml is the BlockDeployer. It has read/write-access to wiring.xml.

- Is it correct that the "contract" between BlockDeployer and BlockManager
  is "wiring.xml" and _nothing_ else?

- So the only way of changing the wiring is directly via the
filesystem. If we need remote access we could provide a small server
application that is completly independ from Cocoon. This server app
provides (web) services to configure a server app. Could this be a solution?


- After the BlockDeployer did all the necessary things like loading a COB from
a repository, unpacking it into /WEB-INF/blocks/[some-autogenerated-ID] and
changing the wiring.xml, the watchdog registers the change and notifies
the BlockManager. The BlockManager reloads the application and does all
the complicated (magic) classloader stuff + much more.


* Am I correct that we have to make sure only one person uses a deployment
tool and changes wiring.xml?
Maybe by using a temporary locking file?


* How is it possible to uninstall a block? How does the BlockDeployer know
whether it can (physically) delete a previously installed block
because it is not used any more by the BlockManager?



-- Reinhard



Reply via email to