felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Object versions in services
Date Thu, 13 Jun 2013 10:27:27 GMT
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 <fmeschbe@adobe.com> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message