Was Re: [osgi] metadata
Niclas Hedhman wrote:
(sorry for a bit lengthy mail)
On Monday 04 July 2005 20:57, Daniel Fagerstrom wrote:
<snip />
Thanks for the clarification.
Niclas, are you getting up to speed with OSGi?
Well, I am tugging along with OSGi independently of Cocoon.
As you probably know, I am from the Avalon camp, and has been working on
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.
We would need to implement an own for ECM++ and other containers that we
like to support in the short time frame. But when it becomes popular to
develop applications in Eclipse, RCP http://www.eclipse.org/rcp/, Cocoon
with real blocks ;) etc, people outside our community will feel need for
using various Component Managers for intra block/bundle/plugin etc
component handling and implement such bundles.
The Cocoon core will probably need to depend on ECM++ for some time, but
the less we make block development depending on any particular
container, the better IMO.
--- o0o ---
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 ?
I am still struggling with some classloading issues. Not sure if it is
Knopflerfish or the OSGi spec, but the Oscar documentation mentioned that
OSGi has tightened up the specification around classloading, i.e. less
permissive.
Any thoughts about how to
use modern component management together with OSGi?
I am no longer sure what "modern component management" would be ;o)
IMHO, Spring's extensive use of XML seems to me to transfer coding from Java
to XML, and remove the type-safety of Java. They say noone has a problem with
it, but I think that is hype.
Agree
I don't have any experience myself with Pico as such, but use CDI (not
automatic) a lot myself.
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?
My view is to choose container at the block level, (the BundleActivator
could e.g. extend a PicoActivator).
together with a pattern called ContextIOC
which I find really intriguing (well, I find the "official" pattern a bit
confusing, but one can boil that down to something with better clarity.)
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.
Another aspect, is that it is possible to push a lot more of the so called
"component management" over to "Build Time", and end up with "sealed
components" that are already "resolved and configured". Such "sealed
component" could end up as a Bundle for deployment, or even just a marshalled
serialized binary ready to be put into action.
All these are experiments that are being conducted and probably not relevant
to Cocoon.
Back to OSGi;
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.
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.
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 am still a long way from understanding all aspects of OSGi. But to me one
thing is fairly clear; The platform specifications are well balanced,
allowing for rock-solid implementations in the difficult domain of
classloading management.
I like it a lot. I like the way I end up developing, hitting reload button
after a compile. I like to manipulate configs and permissions in runtime. I
like that only a fraction of the application is reloaded.
I have the same experience this far.
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.
/Daniel
