Hi,
> Here is the issue:
> When you/iPOJO call getServiceReferences the framework should returns
> only "accessible" services. "Accessible" means that you (the bundle)
> can access to the service object in term of class loading. So, it
> generally means : must use the same service interface class as the
> provider (that's why providers and consumers should import the same
> package).
>
> So, let's back to getServiceReferences. iPOJO as all the other OSGi
> bundle, relies on it and make the assumption that resulting service
> objects can be used by the bundle.
>
> However, in your case, it's a little more tricky.
> You have two "class" spaces:
> - the space V1 containing the api v1 classes
> - the space V2 containing the api v2 classes
>
> Your manifest are correct and set correctly the import package range:
> so V1 bundles import/ export api [1.0.0,1.0.0] and V2 bundles import/
> export api [2.0.0,2.0.0].
>
> So, if we follow the "Accessible" rules, V2 bundles cannot get
> services exported by V1 bundles (and V1 bundles cannot access to
> services exported by V2 bundles).
>
> but (there is always a but), when a V2 bundles ask for service it
> receives services from V2 bundles, and from V1 bundles... Why? just
> because it sounds tricky to detect accessible services when using OSGi
> Service Factories (used by iPOJO to achieve the laziness) .
>
> So, I don't have any good solution to turn around this issue. In fact,
> I don't know if there is one (if somebody has one, feel free to
> mention it ;-))
I am sorry but I don't understand where is really the issue.
As you said in you message, V2 bundles cannot get services exported by v1
bundles.
So for me that's enough. Why do we need to add some filtering informations.
I have made some tries with OSGi bundles regarding that point. Without
factories, I agree.
What I have noticed is that the PackageAdmin OSGi service provide many
informations that are helpful.
I tried the usage of those two methods:
- ExportedPackage getExportedPackage(Bundle bundle);
- RequiredBundle[] getRequiredBundles(String symbolicName);
Don't you think that you can use that kind of verification to avoid the
issue.
Because as you agreed OSGi knows the "links".
------------------------------------------------------------------------------------------
Here are some sample codes that check the "OSGi links" (Ugly implementations
with many if, for, if, for, if. But it does the job.)
Case 1: Import-Package usage as bnd does.
-------
/**
* Return true if the specified 'bundle' imports some packages of the
'importedBundle'
*/
private boolean isImportedBy(Bundle importedBundle, Bundle bundle)
{
ExportedPackage[] exportedPackages =
getPackageAdmin().getExportedPackages(importedBundle);
if (exportedPackages != null)
{
for (ExportedPackage exportedPackage : exportedPackages)
{
Bundle[] importingBundles =
exportedPackage.getImportingBundles();
if (importingBundles != null)
{
for (Bundle importingBundle : importingBundles)
{
if (importingBundle == bundle)
{
return true;
}
}
}
}
}
return false;
}
Case 2: Require-Bundle usage as done by all the Equinox bundles
-------
/**
* Return true is the specified 'bundle' requires the 'requiredBundle'.
*/
private boolean isRequiredBy(Bundle requiredBundle, Bundle bundle)
{
RequiredBundle[] requiredBundles =
getPackageAdmin().getRequiredBundles(requiredBundle.getSymbolicName());
for (RequiredBundle required : requiredBundles)
{
if (required.getBundle() == requiredBundle)
{
Bundle[] requiringBundles = required.getRequiringBundles();
for (Bundle requiringBundle : requiringBundles)
{
if (requiringBundle == bundle)
{
return true;
}
}
}
}
return false;
}
private PackageAdmin getPackageAdmin()
{
return (PackageAdmin) bundleContext.getService(packageAdminRef);
}
Best,
/Etienne
--
View this message in context:
http://www.nabble.com/iPojo---How-to-create-several-instances-of-the-same-component-installed-in-different-versions-tp23544877p23727316.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
