(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
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.
Exactly.
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. http://oscar-osgi.sourceforge.net/repo/http/.
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.
Yes.
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.
Ok.
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
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.
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
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.
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
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)
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.
/Daniel
