Niclas Hedhman wrote:
On Friday 30 September 2005 04:55, Vadim Gritsenko wrote:
Also, I'm not convinced that blocks should be active (i.e. contain
activator) at all.
Without active participation it is no more than a shared library, and as such
it is very difficult to swap out and replace with a new implementation
without restarting the entire application.
Exactly, it is much easier to stop a service and replace it with a new
implementation but with the same interface.
We should probably separate block's code from block's
instance. It is especially important if you have an ability to pass
parameters into the block. Two Cocoon Applications will not be able to
share single instance of a block if its configuration differs - hence,
block itself is passive and is instantiated by the application.
I have a hard time following this discussion, as "block" is somewhat undefined
in OSGi terms, and _I_ don't feel I understand with it is exactly.
Now, that said, I have assumed that a block bundle consists of 0..n block
services.
That is right. The block service(s) is what defines a block. For now the
block service will use o.a.c.components.blocks.BlockManager as API, but
we should strive for finding something much simpler and less Cocoon
specific.
From an implementation POV a Cocoon block will use a BlockActivator
that reads COB-INF/block.xml that contains a sitemap reference,
component configuration, a sitemap reference, definition of deploy time
parameters and definition of connections to other blocks. It will expose
its components as OSGi services.
...
I am not sure what you mean by "passing parameters into the block". I have an
eirie feeling you are refering to "management" concerns about setting up the
service from the outside, and not runtime concerns during the service call.
Yes we talk about block deploy time parameters. These should IMO be
handled with a OSGi configuration service. But that might be something
that we implement later.
/Daniel
