Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
Vadim Gritsenko wrote:
I'd even say that at this point in time, none of the existing
blocks should be aware of OSGi existence but only Cocoon "Kernel",
which uses OSGi to manage (load/unload) blocks on the fly.
Do you have any specific design for achieving this that you are
going to propose?
But in the end we do agree as it seems :-)
<snip/>
And one active way, where the block contain an own component manager
and an component manager <-> OSGi bridge.
Obviously, each block contains (at least) one sitemap. Each sitemap
creates own component manager. So we have this covered.
You are running ahead ;) we are only talking about "component only"
blocks yet.
So they can have root component manager then :-)
This far there have not been much discussions about how to
add the sitemap aspect to the OSGi based architecture. I have some ideas
about how to achieve it and will write an RT about it. In my design a
block that provides sitemap functionality will register a block service
that then can be used by a central blocks manager block. A block will be
able to have any mix of passive library export, active component export
and export of sitemap services.
So some blocks will contain a sitemap but for most of the current ones
that doesn't make sense as they only export compinents. Ok, in some
sense we can achieve that by having a sitemap without pipeline sections.
Or root component manager :-)
Obviously, component manager has to interoperate with OSGi in order to
get handle on 'parent' component manager ('Parent' here in quotes
because component lookup strategy for that parent manager should
change from what we have today.)
So no surprise here.
This is allready to a large extent implemented, take a look at
o.a.c.core.osgi.
Cool.
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. I
feel that real block should be represented in OSGi as a single 'Cocoon Block
Service'.
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.
If you declare all of the components from all of the blocks, won't they be
available to everybody? IIRC, block must not be able to lookup any other class,
component, pipeline from any other block but only from those wired to it.
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.
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 :-)
<snip/>
Vadim
