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. > 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. In OSGi, it is very straight forward to hand different service instances to different client bundles. It is also possible to register the same "service code" with many instances, each different in its setup. One could! have a ROLE attribute in the registration that the client use for the lookup. And so on. 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. Cheers Niclas
