Thanks... "In addition the service registry makes sure, that D only gets V1 Model service instances and E only gets V2 Model service instances." I assumed the registry would only care about the versions of Producer and Consumer, as the Models aren't bound directly to the service.
On 13 June 2013 09:56, Felix Meschberger <[email protected]> wrote: > Hi > > OSGi wires API by import and export package version. > > In you example of two incompatible model classes, you might have bundle B > export the Model API at version 1.0 and bundle C export the Model API at > version 2.0. > > Your consumer bundles D and E would then import the appropriate Model API > versions such as [1,2) and [2,3). > > The actual Model class objects are then different for D and E (even though > the fully qualified class name is the same). In addition the service > registry makes sure, that D only gets V1 Model service instances and E only > gets V2 Model service instances. > > Hope this helps. > > Regards > Felix > > Am 12.06.2013 um 17:56 schrieb Mark Richards: > > > Hi, > > > > I'm new to this list and hopefully this question isn't too long... please > > let me know if you'd like further details. > > > > Context: I'd like to create a service architecture that represents EIPs, > a > > bit like Camel but more OSGi friendly, however the safe wiring of objects > > must ensure the producers are wired to consumers that provide and > consumer > > compatible versions of the objects. > > > > Problem: How do you handle the versions dependencies of objects used a > > layer beneath the services provided? > > > > I believe this issue also affects the listener model, if you wanted to > use > > a generic listener model like so I'm hoping somebody has already solved > it: > > > > interface Listener<T> { //Listener class is handled by bundle resolution > > void Notify(T event); //but what about this T? > > } > > > > > > When you create an implementation you usually know T, so it's quite easy > to > > call "bundleContext.register(Listener.class, this, props)" where props > > includes {"listenerOf":"t.class}" and to then filter the class. However, > > I'm not sure where to get the version for T from (it may be an imported > > class) and versions are ranges with different rules for import and > export. > > > > Any help advice or also, an idea of whether I'm the only one trying to do > > this would be useful. > > > > Thanks, > > Mark > > > > > > Ps: if it helps here is an example of the style of problem in semi-pseudo > > code. > > If you cannot filter the version of the Model through the services layer > > ModelProvider will provide a Date object and ModelConsumer will try to > read > > a Long. The two shouldn't be allowed to bind to each other. > > > > > > bundle A: wiring-api > > interface Provider<T> { > > T giveMeAnObject(); > > } > > interface Consumer<T> { > > void hereIsAnObject(T object); > > } > > > > bundle B: model version 1: > > class Model { > > long getDate();{ return (long) 99 } > > } > > > > bundle C: model version 2: > > class Model { > > Date getDate() { return new Date(); } > > } > > > > bundle D: model-provder version 2: import-packages wiring-api 1 and > model 2 > > class ModelProvider implements Provider <Model> implements > > BundleActivator { { > > void start(BundleContext context) { > > context.register(Provider.class, this, ???? )* // here you'd > > need to specify it is model 2, but how do you get this* > > } > > Model giveMeAnObject() { > > return new Model(); > > } > > } > > bundle E: consumer imports wiring-api and model 1: > > class ModelConsumer implements Consumer<Model>, BundleActivator { > > void start(BundleContext context) { > > context.register(Consumer.class, this, ???? )* // here you'd > > need to specify it is model 1, but how do you get this** > > * }* > > * > > > > void hereIsAnObject(Model object) { > > System.out.println(Long.valueOf(model.getDate())); // if no > > object version filtering this will fail as bundle D should not be > connected > > to bundle E > > } > > } > > > > // here I envisage there should be a Provider Manager perhaps along the > > lines of that could be exposed to have wiring done through a UI, > interface > > or config settings like WireAdmin > > // this isn't too important at this point, except it would need some way > to > > manage this *version filtering/matching*! > > bundle F: provider-service imports wiring-api > > class ProviderManager { > > Map<ClassVersion, Provider> providers; > > Map<ClassVersion, Consumer, consumers > > void registerProvider(ClassVersion<T> provided, Provider<T> > > provider); > > void registerConsumer(ClassVersion<T> consumed, Consumer<T> > > provider); > > > > // methods to lookup and match providers with consumers > > } > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
