cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [osgi] Component management
Date Tue, 05 Jul 2005 15:15:32 GMT
(I appologize upfront that I'm not explain all the involved concepts for 
those not yet up to speed with OSGi ;) See this as some brainstorming. I 
will try to write somthing more comprehensible and structured, when the 
concepts gets clearer to me.)

Niclas Hedhman wrote:

>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
>>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,
Working on this right now in whiteboard/osgi. I use one Cocoon library 
bundle that contains the cocoon.jar together with all needed jars (there 
should be separate bundles for jars that are used by other blocks, but 
that is a later question). One webapp bundle that contains the samples 
and has "sitemap" as Bundle-Category. One cocoon_servlet bundle that 
finds the "sitemap" bundle, creates a CocoonServlet and register it in 
the http service.

> b) get that to deploy properly 
>in Tomcat et al,
There can be some trickiness in getting that to work as servlet 
containers and an OSGi server has some overlapping concerns, both want 
to take care of Java security and classloading and both might try to 
register new URL protocols, which only is allowed to be done once. 
Servlet containers is neither my interest or something I have expertise 
in, so I hope that others wih expertize and interest jump in and work on 
this area. For my usecases I'm happy with using an OSGi http service, 
the one based on Jetty e.g.

> c) get a block bundle to hook into the monolith,
For pure library bundles (i.e. whithout activator) that contains 
components, one could have some solution where some ECM++ adapter bundle 
searches for such bundles and serve them through the service manager as 
today. But that requires exposing all classes of the library bundles. I 
would prefer a solution like the one that we discussed above where the 
component bundles (blocks) are "active" and register its components as 
services. Then the component container within Cocoon core could look 
through non-internal components through some blocks manager that request 
the bundle context for services.

For blocks exposing sitemap functionality I would like them to register 
some kind of sitemap or cocoon or even processor service that basically 
exposes the o.a.c.Processor interface. This would follow the whiteboard 
pattern where blocks register a cocoon service and a global blocks 
manager detects the registration event and start to delgate appropriate 
requests to it.

I would prefer to have the cocoon service or processor service exposing 
as little Cocoon specifics as possible. That might make it possible to 
base different blocks on different Cocoon versions or even to implement 
processor services that not are related to Cocoon at all, but still 
cooperates with other sitemap blocks.

> 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
>> ?
>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 

We don't need to get everything hot deployable and updatable at the 
beginning, but it should be our long term goal. And explicit life cycle 
handling for components that can be installed updated and removed at 
every moment is tricky and error prone, so some kind of support for it 
is necessary IMO.

>>>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 
>which lead to this preliminary draft
>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.
Seem interesting, especially I like that it puts more emphasis at Java 
design pattern and less on some external container. Anyway, I should 
stop asking about the details in this context, as we certainly not need 
to change IOC strategy right now, rather isolate our current choice as 
much as possible and make it as easy as possible for users to use what 
they want to.

>>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.
Yes, the "ServiceManager" must be plugable to be able to achieve OSGi 
service - component container integration. And that might not be the 
case for some of the popular containers. For ECM++ it shouldn't be a 
problem as we control it. And for other containers, I wouldn't be 
suprised if there starts some OSGi hype in the near future when people 
start to realize what one can do with Eclipse RCP etc, then more people 
will like to use their favourite container whithin a bundle or plugin.

>>Second time I see a refernence to Context IOC
>>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.
Also got that impression.

>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.
Yes I also like it. It will be interesting to see what you produce.

>>>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.
I refered to the persistense aspect, I got some impression that it 
wasn't completely supported from the Eclispe mail list, but I don't 
remember the details. I have no reason to doubt that it supports 
ManagedService and other services.

>>>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.
Yes, that should be emphased, the standard services is a set of 
interfaces that can be implemented in any way we like, if we happen to 
want to use them. They make no assumption on using some particular 
logging framework etc, while concrete implementations obviously do.

>>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 
>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)
Definitively :)

>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)
That is a limiting factor ;), anyway its great to beeing able discuss 
OSGi and component management with someone who allready has experience 
in the field.


View raw message