[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