BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
----- Original message -----
From: Raymond Auge via osgi-dev <osgi-dev@mail.osgi.org>
Sent by: osgi-dev-boun...@mail.osgi.org
To: Milen Dyankov via osgi-dev <osgi-dev@mail.osgi.org>
Cc:
Subject: [EXTERNAL] Re: [osgi-dev] @ConsumerType vs @ProviderType
Date: Wed, Oct 16, 2019 19:06
Let me see if I can take a crack at it! Though I'm often told I also don't understand when I try to explain it. :DSuppose you have an API like so:interface DataHandler {void processData(DataContext context);}This API has 2 interfaces `DataHandler` and `DataContext`Now you happen to know there is a library data.machine-1.2.3.jar which is a data processing engine and to use it all you need to do is publish an OSGi service of type `DataHandler` and it will do some magic.
Since you implement `DataHandler` this interface is sensitive to you as a consumer. If the API were to add a method if would break your code. In this case DataHandler is effectively @ConsumerType. It is a type which is implemented in order to _use_ the API.Now, DataContext is not so sensitive for you in this scenario because you only _recieve_ instances of it. You never have to implement it in your _use_ of the API. In this case DataContext is @ProviderType since it's an interface which only _providers_ implement. Therefore if a new method was added to it, it would _not_ break your code, it _would_ however force the implementers of data.machine-1.2.3.jar to make a new release since they are a _provider_ of the API.So you see, both interfaces are part of the same API, yet one is @ConsumerType (DataHandler) and the other is @ProviderType (DataContext).I hope that helps. Others feel free to correct my understanding and hopefully, I'll finally grok it myself.- RayOn Wed, Oct 16, 2019 at 3:34 PM Milen Dyankov via osgi-dev <osgi-dev@mail.osgi.org> wrote:Welcome to the club ;) I struggled with that myself for a long time.I think I finally got to understand it couple of years ago. Here is how I explained it during one of my talks: https://www.youtube.com/watch?v=hGNrZmr0zz8&feature=youtu.be&t=1569I hope this helps better than me trying to write it all down here.Best,MilenOn Wed, Oct 16, 2019 at 9:15 PM Leschke, Scott via osgi-dev <osgi-dev@mail.osgi.org> wrote:_______________________________________________I’m trying to wrap my head around these two annotations and I’m struggling a bit. Is the perspective of the provider and consumer roles from a bundle perspective or an application perspective?
I’ve read the Semantic Versioning whitepaper a number of times and it doesn’t really clear things up for me definitely.
If an application has an API bundle that only exposes Interfaces and Abstract classes, and those interfaces are implemented by other bundles in the app, are those bundles providers or consumers? My inclination is that they’re providers but then when does a bundle become a consumer? Given that API bundles are compile only (this is the rule right?), would a good rule be that if you implement the interface and export the package it’s in, that type would be @ProviderType, if you don’t implement it it’s @ConsumeType?
It would seem to me that @ProviderType would be the default using this logic, as opposed to @ConsumerType, which leads me to believe that I’m thinking about this wrong.
Any help appreciated as always.
Regards,
Scott Leschke
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev-- _______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--Raymond Augé (@rotty3000)_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
