Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
<snip/>
In the active approach the inter block component handling is
handled through OSGi services. To be able to register a service the
block needs an OSGi Activator class.
(minimally, i'd think block only needs to register it's component
manager service, everything else you can get from it)
There are two main alternatives: register the component manager as a
service or register the components as services. We found the later
alternative more atractive as OSGi allready contains a nice and
flexible service registration and service lookup mechanism. Adding an
extra layer just seemed to complicate things.
Not sure it will fly, though.
First, it means that you are managing 'fine' components with coarse
container.
To be a little bit more exact it is not actual components that are
exposed but component factories.
I feel that real block should be represented in OSGi as a single
'Cocoon Block Service'.
That would IMO make the block architecture unnecesarilly monolithic. For
exporting a sitemap service it makes sense to export some kind of Cocoon
block service, we need a service that can take a request object and
return a response object and above that fullfill some protocol for block
attributes and polymorphic sitemap extension, that seem rather Cocoon
specific.
But exporting components, why should that be part of the service that
exports sitemap functionality? Furthermore, the concept of components is
not specific to Cocoon even if their specific interfaces or container
might be, so why should the registration an lookup of components
(services) be tied to the sitemap functionality or something Cocoon
specific whatsoever.
By making our block architecture as Cocoon agnostic as possible at the
inter block level we makes it much easier to use it together with
externally developed blocks (bundles). Also OSGi already have good
mechanisms for service registration, lookup and event handling, no need
to reinvent or circumvent it at the inter block level.
Second, block is wired to several other blocks, and all (java classes,
components, pipelines) it can see must be either in the Cocoon Core or
in one of the blocks which are wired to it.
OSGi R3 does not have any concept of one bundle depending on another,
they depend on and exposes packages.
If you declare all of the components from all of the blocks, won't
they be available to everybody?
Only to those who import them. Furthermore there are Java security based
mechanisms in OSGi for giving detailed access control between bundles, I
have no idea about how it is used though.
IIRC, block must not be able to lookup any other class, component,
pipeline from any other block but only from those wired to it.
At the class level you get something similar by declaring what packages
the block import. At component level, you can connect a Map with any
content to a service, then you can use a subset of the LDAP query
language on these maps during lookup, so each component factory that is
registred as an OSGi service could certainly be namespaced with a block
name if we want to. Then the inter block component lookup mechanism can
limit its search to blocks that are declared to be connected. Something
similar can be used for refering to pipelines in other blocks.
So at the time of block loading, 'block(s) loader/manager' can lookup
Cocoon Block service instances for all blocks referenced from this
one, and pass these services to the block, and after that block can
lookup everything it needs autonomly.
As indicated above this can be solved without needing a monolithic
Cocoon Block service. The advantage with not having such a central point
is that it imposes less Cocoon specific restrictions on blocks and also
that it makes it easier to use the mechanisms that allready are provided
by OSGi for service register/unregister events.
The Cocoon Kernel will have to have an 'OSGi Activator', but not
each block. You are not seriously planning to force each block
developer to start creating their own activators, right? It's
implemented once in kernel, and referenced across all blocks.
Yes
That was my point - blocks won't have OSGi code :-)
Sure, there where some fine details to clarify though ;)
/Daniel
