>From: Scott Lewis <[email protected]>
>I have a couple of questions about this logic
>
>1) Is this 'extender' notion part of the existing specification...or
>it's just not been specified yet?
Extender is a concept and not really a specification. I'm sure others have different definitions of what an extender is but here is my take. An extender is a bundle which performs some bit of work on behave of another bundle. Typically an extender reads some bit of metadata from a bundle (an extendee) that gives the extender some idea of what is needed. DS and blueprint specifications are examples of the extender pattern. In DS the extender reads component xml files to determine what service components are available, resolved and ready to go. The extender will then may register the service component as an OSGi service. In the DS case the extender registers the service components using the extendee's bundle context. This is so that from a system's point of view the service is being provided by the extendee NOT the extender bundle.
In your case I don't think you are reading metadata from extendee bundles. Instead you are paying attention to service events to guess what services various bundles (extendees?) need and then you try to discover them and register any remove services available. To fall under the extender pattern from above you would technically need to register the service under the extendee bundle. But that makes no sense in your scenario because who really is the extendee bundle? What is being proposed here is that you have a dummy bundle that is used to register these other services.
>2) If a bundle can create, install, manage, etc a new bundle that
>satisfies this extender condition...and then use it to register a
>ServiceFactory, then why can't it simply register a ServiceFactory
>directly? That is...why is it necessary to have an extender at all?
To influence the framework so it can detect that your ServiceFactory is wacky (and knows what it is doing). The issue is that the framework must not assume every other ServiceFactory is wacky (or smart like yours). In the normal ServiceFactory case we assume the class space consistency check needs to be done by the framework. In extender case we assume the ServiceFactory will do the necessary checks to make sure there is a consistent class space. Note that this dummy bundle does not have to be created on the fly. You can deliver a prebuilt dummy bundle with ECF if you like.
>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.
Tom
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
