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. And one active way, where the block contain an own
component manager and an component manager <-> OSGi bridge. 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. 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.
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. Also it gives the possiblity to use different component
containers in different blocks in an interoperable way (ECM++, Spring,
Pico etc).
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. 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.
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.
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.
--- 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.
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.
/Daniel
