[jboss-dev-forums] [Design of OSGi Integration] - Current roadmap
alesj
do-not-reply at jboss.com
Tue Jan 20 06:44:03 EST 2009
With JBoss5 out, it's time to get back to OSGi impl work. ;-)
Taking it step-by-step, let's first check what we have and how to move fwd from this.
OSGi = classloading + core frmwrk + services
1) Classloading
Adrian already did most of the work,
it's just a few details left to polish.
Since new CL is metadata driven,
all we need to do is provide a proper:
* OSGi manifest.mf parsing
* OSGi manifest metadata --> JBoss CL metadata transformation
1a) OSGi manifest parsing
Currently it's based on JavaCC and I'm not very happy with it. :-(
* Do we proceed with fixing/enhancing current impl?
* Or do we check some existing - Felix, Equinox, ... (what license do we need to re-use it)?
1b) OSGi manifest metadata --> JBoss CL metadata transformation
This step mostly needs thorough testing,
OSGi's feature by feature --> mapping it to JBoss CL metadata.
This way we'll also see if we cover all features in our CL.
2) Core OSGi framework as a facade
First step: enable OSGi TCK env
Next steps:
a) BundleContext and services
This needs proper impl on top of DeploymentUnit/Context.
Services need proper registry - simple/smart api behind maps.
b) BundleActivationPolicy
This is a new feature - from 4.2 spec.
I guess we'll need some sort of a hook into Classloaders?
e.g. the spec says to only enable BundleActivator if some class from the bundle is accessed
c) listeners and events
I did some work, but I think it needs more wiring inside the MC Kernel itself.
OSGi eventing should drive the listener/event introduction in the MC Kernel.
d) BundleActivator
This is a simple deployer - which already exists.
It's the previous tasks that need to be done before to make this run.
e) DeclarativeServices
Perhaps we can use similar concept to what we've done with MC-Spring-int?
Mapping Spring's schema to MC beans metadata,
where here we would map DS schema to MC beans schema.
In any case, this is optional.
We should eventually support the new OSGi RFC 124.
3) Services
No intention of impl it.
Dunno how much the OSGi TCK tests this things.
I think we should at least test the main services - logging, http, ... -
how well they run in our frmwrk impl.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203198#4203198
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203198
More information about the jboss-dev-forums
mailing list