Updated OSGi/MC prototype

[adrian.brock]

Since Ales and Thomas have been nagging me (you should already know
I don't respond to private e-mails for open source stuff - use the forums :-)
I've committed what I've done so far for the OSGi implementation on top of the
deployers/classloading.

I've kind of changed the priorities for this prototype to do it in a more incremental way.

The basic priority is to be able to deploy osgi bundles within JBoss5+ and use
the OSGi api if you are an osgi deployment. With that in mind I've reworked the
previous prototype to do only that for now.

I realised after trying to "fix" the previous prototype and then failing in that, rewriting it
but trying to do all the changes at once was getting messy and those changes
(e.g. to the classloading or MC) would make it very hard to "drop in" the osgi
layer into existing versions of JBoss5.

So what I've committed is a cut down version of the "rewrite" which while incomplete
(at the moment) does most of the stuff that you want to do with OSGi.

I've removed the old code that is no longer used.

[adrian.brock]

I'll deal with what is missing on different threads by topic, but you can see
what they are if you scan for "todo"s in the code.
A lot of these are duplicates of the same issue so there are actually a lot less
than the 93 todo items currently in existance. I estimate it more like 25-30 of which about 10
are writing proper tests for things that should already work.

[adrian.brock]

I'll explain the architecture of the rewrite so you can understand how it works.

The old prototype had lots of different elements scattered around which made
it not very easy to implement things.

I've replaced them with essentially two main items, OSGiBundleState and
OSGiServiceState which then have "proxies/facades" for the standard OSGi api.

BUNDLES

The OSGiBundleState is little more than a facade over a top level DeploymentUnit.

Every deployment goes through the OSGiBundleStateDeployer which creates an
OSGiBundleState wrapper for that deployment.
They are all registered in an OSGiBundleManager such that the bundle query stuff
can work - and other system level data/services can be configured/reached on that item.

The OSGiBundleState is added as an attachment to the deployment.
This doesn't mean it is an OSGi deployment (that is controlled by whether the
deployment has an OSGiMetaData attachment). What it means is that
you can write other deployers like the OSGiBundleActivatorDeployer
that can see what the Bundle is for a deployment.

When we come to do the service layer properly, we should also add
the OSGiBundleState to the DEPLOYMENT MDR scope so any MC context
can know which "bundle" it belongs to.

The OSGiBundleState has two "facades" the standard Bundle and the BundleContext
interfaces. Of course, there's a special implementation of the OSGiBundleState
for the "system bundle" which works slightly differently.

SERVICES

The service layer is not so well integrated with the MC. It does just enough to
be "OSGi compliant" (of course that's not yet tested). So this is at the
moment very simple.
The OSGiServiceState which should eventually turn into an MC context implementation
has two "facades", the standard ServiceRegistration and ServiceReference interfaces.