-
-
2. Re: Service mix part deux (II.)
alesj Jan 8, 2010 5:47 AM (in response to 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)