On 2/22/11 14:23, Scott Lewis wrote:
But I'm sort of wondering...why couldn't/shouldn't every
ServiceFactory be considered 'wacky'? :)
In the good old days, bundles did not register services for other
bundles, thus all service factories came from the bundle providing the
service. Such service factories typically had access to the classes
listed in objectClass, so this was not complicated. Once we added
Bundle.getBundleContext(), well, all bets were off...
Or maybe there could be some standard service property to signal the
ServiceFactory wackiness? All I'm suggesting is that for this use
case (and others), wouldn't it be better to have some simpler way to
signal this ServiceFactory wackiness...than to have a dummy bundle?
Possibly, like explicitly letting the service factory tell us if they
are class space compatible by giving them the target type from the consumer.
-> richard
p.s. The Felix framework has included special treatment for service
factories since version 2.0.2 (see FELIX-1754).
>3) Which versions of Equinox and Felix have this extender logic...and
>is
>it possible to do something that will work properly (or at least
>tolerably) on older versions of the framework?
This behavior is in Equinox 3.7 M3 or greater, I am not sure on the
Felix version.
>
>I had thought from BJ's notes that imports (of the service type
>packages
>+ versions) would be needed in the dummy bundle. Is that not
>correct?
>More generally, what must this dummy bundle consist of?
Simply have a META-INF/MANFEST.MF that specifies the following with
no need for Import-Package, Require-Bundle etc.
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.eclipse.ecf.remote.service.host
Bundle-Version: 1.0
Note that this bundle needs to be active at runtime so that you can
get its BundleContext to register the services against.
>Finally...dummy
>bundle creation code that satisfies the necessary extender bundle
>conditions would be much appreciated (as I don't want to fumble
>around
>with creating an extender that isn't structured as necessary, etc).
Just build this dummy bundle and deliver it with ECF like any other
bundle you require to function.
Ok...thanks. I will look into both BJ's dynamic dummy code and this
approach (a static dummy)...and with some input about how/whether/what
version Felix support this extender notion...make some decision about
which way to go (as like I said, we want to be
standard/cross-framework, as well as support as many versions of the
framework impls as possible).
Thanks for the help/input.
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
