Hi Am 13.06.2013 um 12:18 schrieb Mark Richards:
> 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. The service registry does not care for versions at all. It cares to make sure a consumer (retrieving the service) can use the service by making sure, the consumer and the service object see the same service object class objects and thus are compatible. Regards Felix > > > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
