Hi Thomas,
On 2/22/2011 10:45 AM, Thomas Watson wrote:
>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.
So as I understand it, the RSA use case for the extender is as follows
(feel free to correct, I may not be stating things correctly):
1) RSA consumers discover EndpointDescriptions (via some discovery
mechanism). EndpointDescriptions essentially are meta-data about the
remotely available service (e.g. it's endpoint id, it's service.id on
remote framework, it's frameworkUUID, other meta-data represented as
properties, etc).
2) The discovered enpdoint description is passed to an implementation of
RemoteServiceAdmin.importService(EndpointDescription)
2) Some bundle that's part of the RSA impl (e.g. the ECF Remote Service
Admin implementation bundle, or the bundle that implements the topology
manager in use) takes the EndpointDescription and uses it to create a
ServiceFactory (for creating proxys) and registered via somebody's
Bundle Context.
3) When consumers attempt to access the proxy ServiceFactory for the
first time, the ServiceFactory.getService method is called by the
framework...and the proxy consumer Bundle is passed into
ServiceFactory.getService()
4) In impl of getService, we use the Bundle passed into the proxy
Service Factory to first load the service type class(es)...using the
consumer Bundle to do so...to assure that the consumer is able to access
the appropriate version of service type. This is my understanding of
what is expressed in the 122.5.6 section of the RSA spec.
5) Still within getService impl, we use the loaded service types to
construct a proxy dynamically and return it from getService
As per the title of this thread, if the ServiceFactory registered in 4
doesn't result in a registered service event delivered to ServiceTracker
(because the ServiceTracker's ServiceReference.isAssignableFrom returns
false...without the extender), then the would be proxy consumers never
end up calling getService and the actual proxy never gets created.
>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.
Ok...this is helpful info (prebuilt dummy bundle)...I'm not sure which
we will go with.
But I'm sort of wondering...why couldn't/shouldn't every ServiceFactory
be considered 'wacky'? :) 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?
>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
