Hi Peter,
Although I'm very happy to hear this, I've been running/testing on 3.7M4
version of Equinox and I'm still seeing the problem (i.e. proxy
ServiceFactory registered by TM bundle...without dynamic
import:*...still doesn't pass compatibility check).
Maybe I need to do something else to trigger this new behavior (?)...if
so please let me know. Do you (or Guillaume) have a bug number for the
ServiceFactory bug?
Thanks all for the help with this.
Scott
On 2/21/2011 7:33 AM, Peter Kriens wrote:
Did some deeper digging and I think we have an interesting issue.
ECF RSA should work with +M3 release of 3.7 Equinox. It turns out that a bug
requested by Guillaume Nodet relaxed the rules for Service Factory services. If
the registrant of the service cannot see the package for any of the service
name classes then it is assumed that he Service Factory will do the right
thing. So with a Service Factory you should be able to register an appropriate
proxy for each bundle, at least in equinox.
Unfortunately, there seems to be some inconsistency here between the
frameworks. I will get to the bottom of this.
Kind regards,
Peter Kriens
On 21 feb 2011, at 11:49, Peter Kriens wrote:
I think we have think a bit deeper. Assume you have 2 exporters of IFoo that
are both compatible with the proxy you generate. Shouldn't you create a proxy
for both?
I think the only viable solution is to register the proxy with each distinct
exporter of IFoo's package for which you're compatible with to ensure you do
not leave anybody out in the cold.
Logically, 4.3's new registerService(Class<S>,S,Map) method should provide you with
the capability but I am afraid the current definition of the compatibility is in limbo
because it is unfortunately defined in terms of isAssignableTo, which unfortunately is
string based instead of class based. I think we need to define a Class<?> version of
this method that we then use for compatibility when possible. This will allow you to
register objects from the DP that are compatible with other bundles even though you do not
import the service interfaces. I file an errata so this is looked into.
Oh, how I long for the days of OSGi R3 when we did not have multiple versions
:-(
Kind regards,
Peter Kriens
On 21 feb 2011, at 07:00, Scott Lewis wrote:
On 2/20/2011 6:14 PM, BJ Hargrave wrote:
<stuff deleted>
You could use dynamic import package but that has some drawbacks. First you
would need to actually load the type(s) to force the framework to establish
the wires before you register the service. Second, you could only support one
version of the package could be a big limitation.
Yes, I see how supporting only one version of a package could be a big
limitation.
This is why I previously suggested dynamically creating, installing and starting a bundle
which has the proper import package statement. This bundle does not need any classes in
it. You just need an "anchor" to use for its class loader to access the types
and for its context to register the service. The actual work can be done by your bundle.
Make sure to properly uninstall this bundle when no longer necessary. There can be many
of these bundles for different service types.
Forgive me, but this approach seems kind of clumsy and complex to manage to
me...as it could be necessary to create, install, start and manage/uninstall a
lot of these dynamic bundles...i.e. one for each distinct imported remote
service.
Are there any viable approaches other than this? e.g. can the wiring of the
RSA (or TopologyManager) bundle be dynamically manipulated...to allow the RSA
or TM itself to register the proxy service factory?
Thanks,
Scott
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
