felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Richards <mark.alan.richa...@gmail.com>
Subject Object versions in services
Date Wed, 12 Jun 2013 15:56:44 GMT

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.


Ps: if it helps here is an example of the style of problem in semi-pseudo
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>
        void registerConsumer(ClassVersion<T> consumed, Consumer<T>

       // methods to lookup and match providers with consumers

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message