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.
Why?
Do you have any specific design for achieving this that you are
going to propose?
May be I skipped important message - is there any reason why block's
classes has to import OSGi?
Yes. There are two main ways of handling blocks with OSGi, one
passive way that I describe in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112362483115086&w=2
and that we have implemented part of, for testing the concept, in the
template block.
How tis 'passive' way solves dynamic unloading of blocks? And
particularly I don't like 'build time configuration'. Does not sound
like real blocks to me. Moving on...
It is not that bad, some central blocks manager can register a listener
for installation, update and uninstallation of bundles. It can then
check the bundle that has change state for a configuration file and
handle it accordingly: i.e. register its components, update them or
unregister them. So it can be made dynamic, still it requires all
packages to be exported and requires everything to be handled of the
central component manager (ECM++). So it is not as scalable as the
active approach.
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. 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.
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.
Sylvain have started to implement the later approach, see
http://marc.theaimsgroup.com/?t=112231957500003&r=1&w=2.
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.
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
<snip/>
If we follow the passive approach all blocks need manifest files
where all packages are exported. Also we need to implement some
mechanisms for using the configuration from the block, (as described
in more detail in the reference above).
In the active approach we need to continue the work that Sylvain has
started, and we need to decide what to export from each block -
everything or just the API.
Best would be API only; if it makes prototyping easier - exporting
everything is Ok tradeoff for a time being.
We probably have to start by exporting about everything, but we should
strive to refactor it to only export APIs.
<snip/>
--- o0o ---
We should IMO make a clear distinction between intra and inter block
aspects: within current blocks we should not require any OSGi use,
thing should work as before. But as inter block apects are
essentially new functionallity we shouldn't beforehand limit
ourselves and instead use the best technical solution available.
To me 'best technical solution' should blend in inter block aspects
into ServiceManager (as additional syntax for role?
This is basically what is done in o.a.c.core.osgi, and there is a new
"exported=true" attribute for exporting components from the block.
or new component such as BlockManager?),
That is my idea for blocks with sitemap functionality, they have an
internal BlockManager and exports a block service.
possibly even without direct access to OSGi internals so that
implementation details of block management are hidden.
As a side effect, blocks won't need much (if any) code changes
(package restructuring excluded).
That is the intension.
<snip/>
/Daniel
