Service mix part deux (II.)

[alesj]

Starting a new fresh thread, as the old one is pretty much tangled up
with a bunch of useless tracking-impl info.
* http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160504

OK, I have cleaned up OSGi MC Facade to work directly off ContextTracker and ContextQueries:
* OSGiManager registeredServices --> controller/context queries
* AbstractBundleState servicesInUse --> context tracker getUsedContexts
* OSGiServiceState usedBundles --> context tracker getUsers(this)

I currently just imitated previous behavior,
explicitly using just OSGi notions - no non-OSGi+MC context usage yet.

So my question is:
(a) how do we handle non-OSGi context in OSGi Facade
(b) how do we handle OSGi services with additional properties in non-OSGi

I guess (b) should be simple.
e.g. as we already discussed, put service's properties into MDR/Instance
and allow for context filtering based on those properties.
But otherwise the plain usage should be type matching, on exposed service's classes.

What about (a)?

What is MC POJO's bundle?
I guess this is why every deployment has OSGiBundleState, which is what we should return / use?
And I guess this - JBDEPLOY-65 - is needed to make a mapping from context to deployment unit --> OSGiBundleState?

[alesj]

Initial service mixture test:
* http://anonsvn.jboss.org/repos/jbossas/projects/jboss-osgi/projects/runtime/framework/trunk/src/test/java/org/jboss/test/osgi/service/ServiceMixUnitTestCase.java

[alesj]

Thomas wrote:

(a) why do you generate dummy bundles in OSGiBundleManager::getBundleForContext
(b) why is the AbstractOSGiBundleStateDeployer split up in two?
(c) how does class space consistency work with these generated bundles
(d) what is OSGiBundleManager::applyMDRUsage

(a) Initial design by Adrian treated all deployments as bundles. At one point you changed this w/o proper explanation.

But since if we want to have proper component mix, we need non OSGi components to behave as ServiceRefs,

which means they have to be able to expose they owning deployments as bundles.

If the initial design stayed as it is (now invalid) described in OSGiBundleStateAddDeployer,

there would be no op to expose the "artificial" bundle, in this case I create one on-the-fly.

If we properly discuss initial design and your changes, this is definitely a subject to discuss as well.

(b) The split is made to properly cleanup all created bundles:

* true OSGi bundles

* on-the-fly "artificial" bundles

Since we only create true bundles in Add deployer, but need to destroy them all in Remove deployer.

(c) They have no, nor should have any, influence on class space consistency.

All the class dependency / space resolution should be resolved before in previous deployment stages,

as you can only create such "artificial" bundle once your components are fully installed, which is in Real stage.

(d) MC-OSGi-facade framework's component/services have been re-writen in such way that they are component type agnostic.

To enable this transparency, we do most of the properties/dictionary lookup work in the MC's generic place for this kind of things == MDR.

This way each different MC service component type is able to participate in OSGi's way of ordering, filtering, ... (1)

Otoh, by using generic MDR way, we can transparently handle OSGi services inside plain Kernel code. (2)

(1) is handled by InstanceMetaDataRetrievalFactory, where we place proper Dictionary under INSTANCE scoped MetaData.

(2) is handled by QualifierMatchers, where we can filter bean's injection via OSGi's LDAP filtering (see FilterParserAndMatcher)