cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [osgi] Component management
Date Tue, 05 Jul 2005 03:21:19 GMT
On Tuesday 05 July 2005 06:10, Daniel Fagerstrom wrote:
> Niclas Hedhman wrote:

> > running Metro (p.k.a Merlin) on top of OSGi, where the Avalon components
> > are exposed as OSGi services as well as ServiceManager.lookup() resolves
> > to OSGi services if no 'local implementations' within the Metro container
> > exist.

> Interesting indeed! I have thought about something like that for Cocoon.
> I.e. handling all inter block (bundle) component lookup as OSGi
> services. In this way one can use different component containers in
> different blocks. Also such OSGi aware component containers would not
> need to know anything about Cocoon and its interfaces.

Yes, that sounds very reasonable, I would even dare to go one step further and 
say that I could implement a block without any component manager. If Cocoon 
Core exposes relevant services, which my block can hook into, it is from 
Cocoon's pespective fairly uninteresting how the functionality is achieved.

> We would need to implement an own for ECM++ and other containers that we
> like to support in the short time frame. 

This is about stepping on new turf, and I am sure it is not possible to have 
all the answers straight away. I think a couple of phases will occur, a) get 
the whole of existing Cocoon to be a Bundle, b) get that to deploy properly 
in Tomcat et al, c) get a block bundle to hook into the monolith, d) refactor 
out core parts that can be seen as optional into bundles, and so on... Many 
lessons will be learnt on the way, just like Cocoon of today has emerged from 
past experiences.

> Could you tell more about your architecture works? In particular how you
> handle the hot plugability of bundles. Are you using dynamic proxies or
> something like that
> http://www.aqute.biz/2005/06/simple-osgi-components.html ?

Not at the moment. I am depending on that the Bundle creator does his part 
properly. Whether to go with byte code manipulation, as suggested by Mr 
Kriens, or having something a bit more explicit is something to think about. 
My primary goal is to get Metro to work, and it has its own Proxy isolation 
between services already in place, so it is a matter of taking advantage of 
that.

> > Lately, I have been working with an explicit custom management side. That
> > means that each component is free to define its own management
> > requirement, and optionally implement it if no existing pattern exists.
> > That means that Pico and Spring *could* co-exist,
>
> How do you handle that, any references?

This started out with me and Stephen McConnell in the same room and my white 
board.
  http://www.dpml.net/about/notepad/freight/brainstorming.html
which lead to this preliminary draft
  http://www.dpml.net/about/notepad/freight/development.html

We use very little meta information, and rely on naming conventions. This is 
just a choice and less relevant.
In the development.html page, it is not described that the ContextManager is 
assembled in build time and "packaged" together with the component. Again, 
implementation details probably not relevant in this context.

> My view is to choose container at the block level, (the BundleActivator
> could e.g. extend a PicoActivator).

Yes, that could be reasonable. You may face problems to hook into the 
Pico/Spring internals though. I was not able to make what I wanted in Metro 
without touching the guts, i.e. changing the ServiceManager to understand the 
BundleContext for retrieval of external services, and changes to the 'Model' 
that Services are to be registered with OSGi. Not too hard, but right now 
creates a fork of the codebase, and I want to avoid that and that is a much 
bigger challenge.


> Second time I see a refernence to Context IOC
> http://www.theserverside.com/articles/content/IOCandEJB/article.html,
> this time when I read the article again, it started to make sense to me
> ;) Seems interesting.

We have chosen to use a subset of the proposal in the above article. Reason 
being that it can become very confusing, and makes generic implementation 
fairly complicated.

What is important to notice is that it improves testability quite a bit, and 
IMHO it communicates "intent" in the code fairly well, compared to anything 
else I have seen so far. And it is a pattern one can use without relying on 
containers, if one wants that.

> > The fact that bundles can be loaded, then manipulated (config,
> > permissions, ++) and finally the entire OSGi platform saved into a
> > deployment bundle is also an interesting aspect.
>
> I'm not certain that the Eclipse OSGi implementation does this.

Well, maybe not out of the box, but the specification allows for it, and I am 
pretty sure their OSGi implementation don't break the spec intentionally. 
Also, the configurable parts must co-operate thru the ManagedService 
interface and the write back of config to the ServiceRegistration, and 
perhaps Eclipse have chosen not to use it in their bundles.

> > For Cocoon it should mean that all services that has configuration,
> > should implement ManagedService and store all their config state in the
> > ServiceRegistration. Which means one can tune the running server and no
> > need to worry about that getting lost on restarts.
>
> Note to other readers: This means that configurations are handled by a
> certain Configuration admin service that is a standard service from
> OSGi. Both Knopflerfish and Oscar has free implementations, of it.

Yes. OTOH, nothing prevents someone from creating a bundle implementing the 
Config Admin Service, which in turn is a full Cocoon application with forms 
and stuff. And it can co-exist, co-run with other Config Admin Services.

> For the moment I don't know how much we should use standard services:
> log service, configuration admin, URL handler service, http service etc.
> I think we can decide this when we start to understand more about how
> the architecture.

I think that is a wise general principle. Once it is made, it is also not 
necessarily a final decision :o)


> > BUT, it is easy to
> > make mistakes keeping references to old instances in other bundles,
> > causing all kinds of problems. So great care required! :o)
>
> Not so cool. Hopefully we can provide infrastructure that help users
> keeping track on the dependencies.

Yes, the mentioned Proxy injection is probably something one should figure out 
at some point. Perhaps it is a matter of priority and demand more from the 
block developers initially, and then lax it later with better 
tools/techniques.


IMHO, Cocoon has a lot of fun time ahead of itself, especially if this 
exercise can occur with disruption. Once some initial steps are taken, I 
think a fair bit of the Core internals can be 'migrated' away from ECM++ bit 
by bit, and a golden opportunity to increase the body mass of people having a 
clue how the core internals work ;o)
If I had more Cocoon work than I have, I would throw more cycles your way, but 
right now I need to concentrate on process control and industrial automation 
stuff. One have to eat :o)

Cheers
Niclas

Mime
View raw message