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...
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.
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.
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)
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.
Our hope is that it will be enough with a
generic ServiceManagerActivator that the block just refer to in the
manifest, but we don't know that yet.
Exactly my point.
The active approach is preferable to the passive one as it makes it
possible for the block to just expose the API, the implementation can be
shielded.
Sounds good.
Also it gives the possiblity to use different component
containers in different blocks in an interoperable way (ECM++, Spring,
Pico etc).
Whatever.
Isn't it the first goal to make (any) existing block (with no code
modifications) run under OSGi?
We could do that with the passive approach, although the package
structure needs to be changed in some places. But it seemed like people
prefered to focus on the active approach during the blockathon.
Good.
Wheter
approach we take we must start with fixing the package structure as
discussed before so that each block has unique packages, two blocks with
the same package but with different content will lead to problems'as
discussed before.
Everything has a price, and this is price to have 'active OSGi blocks'.
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.
Anyway, as the active approach is more scalable and the passive one
requires some work to be done that not will be reused if we continue
with the active approach, it seemed better to me (and others) to start
with the active approach right away.
Agreed.
--- 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? or new component such as
BlockManager?), 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).
People, at this point of time it seem rather pointless to me to
impose all sorts of restrictions on how we should implement blocks.
Instead of discussing about how to not implement blocks I would
prefer to focus on discussing how to implement them or even actually
continue implementing them ;)
Sorry, had no time to look at it :-(
I noticed though that currently there is no 'CocoonServler' which
would bootstrap OSGi container, isn't it?
We are still waiting for someone who want it enough to do the work ;)
More seriously I thik we can wait with that until we move to Oscar OSGi.
The mechanism for starting an OSGi framework is not standaridised. And
there migth be some issues with Java security and URL handler
registration when using an OSGi container within a servlet container,
those issues would be easier to handle in an Apache project as Oscar.
I see.
Thanks for the mail,
Vadim
