Re: [osgi-dev] @ConsumerType vs @ProviderType

[Tim Ward via osgi-dev]

Hi Scott,

As the author of the Transaction Control specification I can attempt to explain 
to you the reasoning for the example that is confusing you.

In the Transaction Control specification there are three primary sets of actors:

People implementing the core TransactionControl service (i.e. the transaction 
management piece)
People implementing Transactional Resources (e.g. JDBC wrappers, JPA wrappers, 
JMS wrappers, Transaction Scoped objects)
People using the Transaction Control Service to do transactional work

In many cases there will be overlaps in these groups, but broadly speaking the 
intent of the specification is that people providing transactional resources 
are different from people providing the core transaction service. It is also 
expected (hoped) that there will be many more people providing transactional 
resource providers than there are providing Transaction Control Services. 

For these reasons the generic ResourceProvider interface is annotated with 
@ConsumerType, specifically so users can provide their own custom resource 
providers without becoming providers of the Transaction Control specification.

Now, to answer your question - if you have a specialisation of a @ConsumerType 
interface (as JDBCConnectionProvider and JPAEntityManagerProvider both are) 
then what should the status of that interface be? The general wisdom is that 
Transaction Control Resource Provider specialisations are explicitly supposed 
to be used for reifying the type of the ResourceProvider. This doesn’t change 
the usage intent of the ResourceProvider, and therefore we don’t change the 
@ConsumerType.

On the other hand the various ResourceProvider Factory services *do* feature in 
the specification in the way that other “provider” services do - there are 
rules about what properties you need to support in the configuration maps etc. 
Also, unlike the ResourceProvider interfaces, it’s possible to implement the 
factory service without implementing other Transaction Control interfaces 
(implementing JDBCConnectionProvider requires implementing ResourceProvider). 
We very much want to avoid coupling which would mean that existing Resource 
Provider implementations would not work with a version 1.1 of the Transaction 
Control specification.

In summary - JDBCConnectionProvider is @ConsumerType because ResourceProvider 
is @ConsumerType. ResourceProvider is @ConsumerType because providing a 
transactional resource is not the same as providing a Transaction Control 
service. JDBCConnectionProviderFactory is @ProviderType because by implementing 
it you are a provider of the standardised configuration factory for 
Transactional JDBC resources.

I hope this makes sense.

All the best,

Tim

> On 24 Oct 2019, at 03:53, Leschke, Scott via osgi-dev 
>  wrote:
> 
> First I’d like to thank everybody for their thoughtful responses. I’m sorry 
> that this response was so long in coming. Unfortunately, the demands of my 
> day-to-day, which is unrelated to anything OSGi, has taken quite a bit of my 
> time lately.
>  
> I found all the responses very helpful but I must say that I found Peter’s 
> response below to be extremely helpful especially the last two paragraphs. I 
> do a few question have a specific example taken from the R7 OSGi Compendium 
> spec that I still find confusing though.
>  
> Package org.osgi.service.transaction.control.jdbc provides two interfaces, 
> JDBCConnectionProvider and JDBCConnectionProviderFactory.  The latter is 
> @ProviderType as I’d expect but the former is @ConsumerType.  As a consumer 
> of this API package, my expectation is that I won’t be implementing 
> JDBCConnectionProvider but the API provider, Apache Aries for example, will 
> be so that it should be @ProviderType instead of @ConsumerType since adding 
> methods to this interface won’t impact me as a consumer.
>  
> Am I making any sense? Is it possible for an API to expose an @ConsumerType 
> that isn’t implemented or extended by the consumer role? It would seem not. 
> If that’s the case, is the primary reason the default is @ConsumerType 
> (rather than @ProviderType) because it’s the more conservative choice, rather 
> than the more common one because in my experience, the vast majority of types 
> in an API are implemented by the provider rather than the consumer.
>  
> Thanks so much, I hope I’m not wasting anybody’s time here.
>  
> Scott
>  
> From: Peter Kriens  
> Sent: Thursday, October 17, 2019 12:17 PM
> To: Leschke, Scott ; OSGi Developer Mail List 
> 
> Subject: Re: [osgi-dev] @ConsumerType vs @ProviderType
>  
> It is surprisingly simple. :-)
>  
> Let's assume Oracle adds a new method to `java.nio.file.Path`. Would you 
> care? Unless you work for Azul, you'd like couldn't give a rats ass. Once you 
> use that new method you care, but before that moment it is irrelevant to

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Leschke, Scott via osgi-dev]

First I’d like to thank everybody for their thoughtful responses. I’m sorry 
that this response was so long in coming. Unfortunately, the demands of my 
day-to-day, which is unrelated to anything OSGi, has taken quite a bit of my 
time lately.

I found all the responses very helpful but I must say that I found Peter’s 
response below to be extremely helpful especially the last two paragraphs. I do 
a few question have a specific example taken from the R7 OSGi Compendium spec 
that I still find confusing though.

Package org.osgi.service.transaction.control.jdbc provides two interfaces, 
JDBCConnectionProvider and JDBCConnectionProviderFactory.  The latter is 
@ProviderType as I’d expect but the former is @ConsumerType.  As a consumer of 
this API package, my expectation is that I won’t be implementing 
JDBCConnectionProvider but the API provider, Apache Aries for example, will be 
so that it should be @ProviderType instead of @ConsumerType since adding 
methods to this interface won’t impact me as a consumer.

Am I making any sense? Is it possible for an API to expose an @ConsumerType 
that isn’t implemented or extended by the consumer role? It would seem not. If 
that’s the case, is the primary reason the default is @ConsumerType (rather 
than @ProviderType) because it’s the more conservative choice, rather than the 
more common one because in my experience, the vast majority of types in an API 
are implemented by the provider rather than the consumer.

Thanks so much, I hope I’m not wasting anybody’s time here.

Scott

From: Peter Kriens 
Sent: Thursday, October 17, 2019 12:17 PM
To: Leschke, Scott ; OSGi Developer Mail List 

Subject: Re: [osgi-dev] @ConsumerType vs @ProviderType

It is surprisingly simple. :-)

Let's assume Oracle adds a new method to `java.nio.file.Path`. Would you care? 
Unless you work for Azul, you'd like couldn't give a rats ass. Once you use 
that new method you care, but before that moment it is irrelevant to you. That 
makes you a _consumer_ of the `java.nio.file` package. Azul and Oracle are, 
however, _providers_ of this package. Oracle and Azul do care when this method 
gets added because you would be very upset if the method is not there. However, 
if Oracle added a method to `java.io.Serializable` you would likely be pretty 
upset because you are a _consumer_ of the 
`java.io<https://urldefense.proofpoint.com/v2/url?u=http-3A__java.io=DwMFaQ=ZyuC0pi8BQ0JtN0UhY3DPMRPQOzp-0mvXzAggKz74wI=bjaNw_Ip6Cns5Gp3HC6K_oF-NLagO9fLr68IUFiG2XI=4j5tN615t0CCQkj0qKIfs7DsTPHcY6IZTKcyRWR3-x4=d1IEUgm1-X61sZi0T8Znk33Xo7ggGqLRmuWrUSlYF6k=>`
 package.

When you make a change to an API package you might break users of that package. 
To distinguish between the Azuls and Oracles of this world and mere mortals 
OSGi/bnd allows you to mark a type to be **only** affecting _providers_. I.e. 
the Path interface would be a _provider type_. (The @ConsumerType is default 
and just breaks everybody when you make a binary incompatible change.)

The archetypical example is Event Admin. If we add a method to the EventAmin 
interface we only break the 5 or 6 implementations of Event Admin. And we 
should break those implementation because they need to implement this new 
method. However, the 50 million bundles that depend on Event Admin are not 
affected since this change is fully backward compatible for them. However, if 
we add a method to Event Handler then we break all those 50 million bundles 
that implement Event Handler. That is why  the `EventHandler` interface is a 
@ConsumerType.

So the sole purpose of the @ProviderType annotation is to make a breaking 
change but indicate that only, the usually smaller number of, bundles that 
_provide_ the API should be broken instead of the majority of bundles that only 
_consume_ this API.

The key thing to realize is that provider/consumer is about the API **package** 
and not an interface. If you make a binary incompatible change, the key 
question is does it affect everybody (consumer and providers) or can I limit it 
to a smaller number of bundles (providers)?

PK

On 16 Oct 2019, at 21:15, Leschke, Scott via osgi-dev 
mailto: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, 

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Peter Kriens via osgi-dev]

It is surprisingly simple. :-)

Let's assume Oracle adds a new method to `java.nio.file.Path`. Would you care? 
Unless you work for Azul, you'd like couldn't give a rats ass. Once you use 
that new method you care, but before that moment it is irrelevant to you. That 
makes you a _consumer_ of the `java.nio.file` package. Azul and Oracle are, 
however, _providers_ of this package. Oracle and Azul do care when this method 
gets added because you would be very upset if the method is not there. However, 
if Oracle added a method to `java.io.Serializable` you would likely be pretty 
upset because you are a _consumer_ of the `java.io ` package.

When you make a change to an API package you might break users of that package. 
To distinguish between the Azuls and Oracles of this world and mere mortals 
OSGi/bnd allows you to mark a type to be **only** affecting _providers_. I.e. 
the Path interface would be a _provider type_. (The @ConsumerType is default 
and just breaks everybody when you make a binary incompatible change.)

The archetypical example is Event Admin. If we add a method to the EventAmin 
interface we only break the 5 or 6 implementations of Event Admin. And we 
should break those implementation because they need to implement this new 
method. However, the 50 million bundles that depend on Event Admin are not 
affected since this change is fully backward compatible for them. However, if 
we add a method to Event Handler then we break all those 50 million bundles 
that implement Event Handler. That is why  the `EventHandler` interface is a 
@ConsumerType.

So the sole purpose of the @ProviderType annotation is to make a breaking 
change but indicate that only, the usually smaller number of, bundles that 
_provide_ the API should be broken instead of the majority of bundles that only 
_consume_ this API.

The key thing to realize is that provider/consumer is about the API **package** 
and not an interface. If you make a binary incompatible change, the key 
question is does it affect everybody (consumer and providers) or can I limit it 
to a smaller number of bundles (providers)?

PK

> On 16 Oct 2019, at 21:15, Leschke, Scott via osgi-dev 
>  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

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Raymond Auge via osgi-dev]

On Wed, Oct 16, 2019 at 7:53 PM Greg Amerson via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> And with regards to version increases, if a new method added to
> `DataHandler` that would break API and cause a major version increase for
> the package, however, if a new method was added to `DataContext` since that
> API is marked `@ProviderType` the package version increase would only have
> to be minor.  Is that correct?
>

That is correct!

- Ray


>
> On Wed, Oct 16, 2019 at 6:06 PM Raymond Auge via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
>> 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. :D
>>
>> Suppose 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.
>> - Ray
>>
>>
>> On 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=youtu.be=1569
>>> I hope this helps better than me trying to write it all down here.
>>>
>>> Best,
>>> Milen
>>>
>>> On 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
>>>
>>>
>>>
>>> --
>>> http://about.me/milen
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>>
>> --
>> *Raymond Augé* 
>>  (@rotty3000)
>> Senior Software Architect *Liferay, Inc.* 
>>  (@Liferay)
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> Greg Amerson
> Liferay Developer Tools
> Liferay, Inc. www.liferay.com
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Greg Amerson via osgi-dev]

And with regards to version increases, if a new method added to
`DataHandler` that would break API and cause a major version increase for
the package, however, if a new method was added to `DataContext` since that
API is marked `@ProviderType` the package version increase would only have
to be minor.  Is that correct?

On Wed, Oct 16, 2019 at 6:06 PM Raymond Auge via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> 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. :D
>
> Suppose 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.
> - Ray
>
>
> On 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=youtu.be=1569
>> I hope this helps better than me trying to write it all down here.
>>
>> Best,
>> Milen
>>
>> On 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
>>
>>
>>
>> --
>> http://about.me/milen
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
Greg Amerson
Liferay Developer Tools
Liferay, Inc. www.liferay.com
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] @ConsumerType vs @ProviderType

[BJ Hargrave via osgi-dev]

Nailed it!
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Raymond Auge via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: Milen Dyankov via osgi-dev Cc:Subject: [EXTERNAL] Re: [osgi-dev] @ConsumerType vs @ProviderTypeDate: 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. :D
 
Suppose 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.
- Ray
  

On Wed, Oct 16, 2019 at 3:34 PM Milen Dyankov via osgi-dev  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=youtu.be=1569
I hope this helps better than me trying to write it all down here.
 
Best,
Milen 

On Wed, Oct 16, 2019 at 9:15 PM Leschke, Scott via osgi-dev  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 Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 

 --

http://about.me/milen___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev--
Raymond Augé (@rotty3000)
Senior Software Architect Liferay, Inc. (@Liferay)
___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Raymond Auge via osgi-dev]

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. :D

Suppose 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.
- Ray

On Wed, Oct 16, 2019 at 3: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



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Raymond Auge via osgi-dev]

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. :D

Suppose 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.
- Ray


On 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=youtu.be=1569
> I hope this helps better than me trying to write it all down here.
>
> Best,
> Milen
>
> On 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
>
>
>
> --
> http://about.me/milen
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] @ConsumerType vs @ProviderType

[Milen Dyankov via osgi-dev]

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=youtu.be=1569
I hope this helps better than me trying to write it all down here.

Best,
Milen

On 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



-- 
http://about.me/milen
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] @ConsumerType vs @ProviderType

[Leschke, Scott via osgi-dev]

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