Re: [osgi-dev] Service binding issue and package wiring
Thanks BJ and Ray, It's much clearer now! Clement. ‐‐‐ Original Message ‐‐‐ On Wednesday 11 March 2020 16:45, BJ Hargrave wrote: > If multiple bundles export the identical package (that is, the same class > files containing the same byte codes), the runtime classes are different and > distinct. A Class object is a product of the class file and the class loader > which loads it. > > So when bundle B (exporting its copy of package api.a) loads api.a.Service1 > and bundle C (exporting its copy of package api.a) loads api.a.Service1, > those are two different classes as far as the JVM is concerned. > > Note, when a bundle both exports and imports a package, the framework is free > to resolve the bundle in either state: exporting or importing. So when > multiple bundles both export and import a given package, it is entirely > possible the framework may choose that more then one of the bundles export > the package. Ideally, we would want the framework to select only a single > bundle to export the package and that all other bundles import the package. > But there can be many reasons (such as other class space constraints) which > may cause the framework to export the package from multiple bundles. > > I would recommend you have a API bundle which exports api.a which is usable > at runtime and that all implementation bundles import api.a. > -- > > 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: "Clément Delgrange via osgi-dev" >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List >> Cc: >> Subject: [EXTERNAL] Re: [osgi-dev] Service binding issue and package wiring >> Date: Wed, Mar 11, 2020 10:58 >> >>> Since both bundles B and C offer to export the api.a package, the framework >>> could resolve both bundles to each export the package. Thus you can end up >>> with 2 exports of the api.a package in the framework. So bundle D will >>> import api.a from either bundle B or bundle C and thus will not be able to >>> see the service from the other bundle since it is not type compatible. >> >> Maybe I lack some basic knowledge about Java class loading, but I thought >> that as the packages were at the same version there was nothing that can >> really distinguish them, the framework will choose to use one of the >> packages from a specific location (eg; Bundle B) and so the services could >> not be impacted by a type compatibility issue. This is what I understand >> from the blog post sent by Ray too: "Because the OSGi framework controls the >> classloading on the package level, when multiple bundles export the API >> package(s), the OSGi framework can decide which exporting bundle ultimately >> provides the API package(s) to each bundle importing the API, that is, to >> each API consumer.". But as I can factually see and from your explanation >> things can happen differently?! >> >>> You may want to also look at >>> https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html >> >> Thanks for the link. In the section Going Forward, it is wrote that we >> should consider not embedding API packages that are defined by OSGi >> specifications, does this advice also holds for our own service definitions? >> >> When building a system with multiple related features does it makes sens to >> provide a compile time Bundle with all the API packages, and, one runtime >> API Bundle for each API packages? Is it what the blog post is telling us? >> What is the relation between osgi.cmpn and the set of osgi runtime API >> bundles? >> >> I like to have one API bundle per workspace, it makes dependency management >> easier and I have one unique project to be careful with. Would it be >> relevant that bnd/bndtools provides a support to release multiple runtime >> API Bundles from one API project simply by configuring something in the >> bnd.bnd file. I am not sure to be clear, but this is to control the number >> of projects needed. >> >> Another solution would be to make the API Bundle resolvable, but I had some >> issue with that in the past... >> >> ‐‐‐ Original Message ‐‐‐ >> On Wednesday 11 March 2020 14:19, Raymond Auge >> wrote: >> >>> Hi Clément, >>> >>> You may want to also look at >>> https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html >>> >>> :) >
Re: [osgi-dev] Service binding issue and package wiring
> Since both bundles B and C offer to export the api.a package, the framework > could resolve both bundles to each export the package. Thus you can end up > with 2 exports of the api.a package in the framework. So bundle D will import > api.a from either bundle B or bundle C and thus will not be able to see the > service from the other bundle since it is not type compatible. Maybe I lack some basic knowledge about Java class loading, but I thought that as the packages were at the same version there was nothing that can really distinguish them, the framework will choose to use one of the packages from a specific location (eg; Bundle B) and so the services could not be impacted by a type compatibility issue. This is what I understand from the blog post sent by Ray too: "Because the OSGi framework controls the classloading on the package level, when multiple bundles export the API package(s), the OSGi framework can decide which exporting bundle ultimately provides the API package(s) to each bundle importing the API, that is, to each API consumer.". But as I can factually see and from your explanation things can happen differently?! > You may want to also look at > https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html Thanks for the link. In the section Going Forward, it is wrote that we should consider not embedding API packages that are defined by OSGi specifications, does this advice also holds for our own service definitions? When building a system with multiple related features does it makes sens to provide a compile time Bundle with all the API packages, and, one runtime API Bundle for each API packages? Is it what the blog post is telling us? What is the relation between osgi.cmpn and the set of osgi runtime API bundles? I like to have one API bundle per workspace, it makes dependency management easier and I have one unique project to be careful with. Would it be relevant that bnd/bndtools provides a support to release multiple runtime API Bundles from one API project simply by configuring something in the bnd.bnd file. I am not sure to be clear, but this is to control the number of projects needed. Another solution would be to make the API Bundle resolvable, but I had some issue with that in the past... ‐‐‐ Original Message ‐‐‐ On Wednesday 11 March 2020 14:19, Raymond Auge wrote: > Hi Clément, > > You may want to also look at > https://blog.osgi.org/2020/01/to-embed-or-not-to-embed-your-api.html > > :) > > - Ray > > On Wed, Mar 11, 2020 at 9:16 AM BJ Hargrave via osgi-dev > wrote: > >> Since both bundles B and C offer to export the api.a package, the framework >> could resolve both bundles to each export the package. Thus you can end up >> with 2 exports of the api.a package in the framework. So bundle D will >> import api.a from either bundle B or bundle C and thus will not be able to >> see the service from the other bundle since it is not type compatible. >> >> In this scenario, it is better to have only a single exporter of api.a. >> Bundle A would be the best choice here as it is the original source of the >> package. But you would need to allow it to be resolvable so it can be used >> at runtime. >> -- >> >> 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: "Clément Delgrange via osgi-dev" >>> Sent by: osgi-dev-boun...@mail.osgi.org >>> To: OSGi Developer Mail List >>> Cc: >>> Subject: [EXTERNAL] [osgi-dev] Service binding issue and package wiring >>> Date: Wed, Mar 11, 2020 08:13 >>> >>> Hi all, >>> >>> I have some sparse service binding issues at runtime that I think are >>> related at how my bundles export packages. >>> >>> Here is what I have: >>> - Bundle A exports API package api.a and is not resolvable (not present at >>> runtime). >>> - Bundle B provides api.a.Service1 service and export/import api.a package. >>> - Bundle C provides api.a.Service2 service and export/import api.a package. >>> - Bundle D consumes Service1 or Service2 and import api.a package. >>> >>> In this case is there any reason related to the way packages are wired that >>> could lead bundle D to not get Service1 or Service2? Subsidiary question, >>> is it fine to have an API package partly provided by two different bundles >>> when provider bundles embed their API? >>> >>> In a more general practice, for a specific functionality, I have often one >>> core servi
[osgi-dev] Service binding issue and package wiring
Hi all, I have some sparse service binding issues at runtime that I think are related at how my bundles export packages. Here is what I have: - Bundle A exports API package api.a and is not resolvable (not present at runtime). - Bundle B provides api.a.Service1 service and export/import api.a package. - Bundle C provides api.a.Service2 service and export/import api.a package. - Bundle D consumes Service1 or Service2 and import api.a package. In this case is there any reason related to the way packages are wired that could lead bundle D to not get Service1 or Service2? Subsidiary question, is it fine to have an API package partly provided by two different bundles when provider bundles embed their API? In a more general practice, for a specific functionality, I have often one core service contract, some DTOs and some DAO services. Which one of this combination is better (considering that I have always an unresolvable API bundle and my providers export the API package they provide): - Core service, DAOs and DTOs in one API package then two providers, one for the core service implementation and DTOs and the other for the DAOs implementation. - Core service, DAOs and DTOs split in different API packages then three providers, one for each. Regards, Clement___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] IoT and UPnP protocol
Hi, It is for an experimental work, I need the most spread protocol used in IoT, thought it was UPnP. But, the library do not need to interoperate with the OSGi spec API if you are aware of one which could easily be embedded into an OSGi runtime? ‐‐‐ Original Message ‐‐‐ On Monday 25 November 2019 21:47, Peter Firmstone via osgi-dev wrote: > Do you need UPnP specifically to interoperate with other UPnP devices or are > you simply looking for functionality similar to that which UPnP provides? > > On 11/26/2019 2:26 AM, Clément Delgrange via osgi-dev wrote: > >> Thanks BJ, indeed I have seen this list but I was expecting a free >> implementation too :) I am trying with Felix but without success so far. >> >> ‐‐‐ Original Message ‐‐‐ >> On Monday 25 November 2019 14:12, BJ Hargrave >> [](mailto:hargr...@us.ibm.com) wrote: >> >>> You can look here >>> https://en.wikipedia.org/wiki/OSGi_Specification_Implementations >>> -- >>> >>> 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: "Clément Delgrange via osgi-dev" >>>> [](mailto:osgi-dev@mail.osgi.org) >>>> Sent by: osgi-dev-boun...@mail.osgi.org >>>> To: OSGi Developer Mail List >>>> [](mailto:osgi-dev@mail.osgi.org) >>>> Cc: >>>> Subject: [EXTERNAL] [osgi-dev] IoT and UPnP protocol >>>> Date: Mon, Nov 25, 2019 05:47 >>>> >>>> Hi all, >>>> >>>> Is there an open source implementation of the UPnP specification that >>>> works well and is up-to-date? I found this >>>> http://felix.apache.org/documentation/subprojects/apache-felix-upnp.html >>>> but there are maybe more documented alternatives... >>>> >>>> Thanks, >>>> Clément. >>>> >>>> ___ >>>> 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___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] IoT and UPnP protocol
Thanks BJ, indeed I have seen this list but I was expecting a free implementation too :) I am trying with Felix but without success so far. ‐‐‐ Original Message ‐‐‐ On Monday 25 November 2019 14:12, BJ Hargrave wrote: > You can look here > https://en.wikipedia.org/wiki/OSGi_Specification_Implementations > -- > > 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: "Clément Delgrange via osgi-dev" >> Sent by: osgi-dev-boun...@mail.osgi.org >> To: OSGi Developer Mail List >> Cc: >> Subject: [EXTERNAL] [osgi-dev] IoT and UPnP protocol >> Date: Mon, Nov 25, 2019 05:47 >> >> Hi all, >> >> Is there an open source implementation of the UPnP specification that works >> well and is up-to-date? I found this >> http://felix.apache.org/documentation/subprojects/apache-felix-upnp.html but >> there are maybe more documented alternatives... >> >> Thanks, >> Clément. >> >> ___ >> 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
[osgi-dev] IoT and UPnP protocol
Hi all, Is there an open source implementation of the UPnP specification that works well and is up-to-date? I found this http://felix.apache.org/documentation/subprojects/apache-felix-upnp.html but there are maybe more documented alternatives... Thanks, Clément.___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin
> We explicitely decided against an additional plugin mechanism for the > configurator as that one is not really needed. It's not important what > configuration admin stores (the place holders or the final values) But a ConfigurationPlugin cannot delay a configuration (to not deliver the configuration to the target until a condition is met)? * With the Tim's solution, configuration targets can receive wrong configurations at startup that may trigger wrong behaviors or at least a lot of exceptions in my activate methods. I suppose that with DS and Metatype the system will be more stable, isn't it? It is maybe the best solution in my case. * With Jürgen's possibility 1, service implementations must know how they will be configured. Impossible in my case. * With Jürgen's possibility 2, if my configuration plugin needs a configuration (eg; user/password for a database) it will be never activated!? A configurator plugin would have been easier to implement and would have improved startup stability, no? In any case, thank you for your precious help! Clément. ‐‐‐ Original Message ‐‐‐ On Thursday 10 October 2019 12:12, Carsten Ziegeler via osgi-dev wrote: > We explicitely decided against an additional plugin mechanism for the > configurator as that one is not really needed. It's not important what > configuration admin stores (the place holders or the final values), its > important what configuration admin delivers. And for that use case a > configuration plugin works. > > For your use case you can implement two configuration plugins. > > Regards > Carsten > > --- > > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > > Am 10.10.2019 um 08:37 schrieb Clément Delgrange via osgi-dev: > > > Thanks for your help, > > Jürgen and Tim's solutions could meet my needs, but as BJ said values > > are replaced each time the configuration is delivered to the target and > > as I understand not saved. Maybe it is appropriate just for password and > > secrets. My application configurations generally contain "structural" > > properties (eg; myreference.target=), stable properties (eg; > > url.to.publickey=), properties that change according to the environment > > (cache.policy=) and secret properties. It would be nice if the > > configurator could in addition handle placeholders, if it was the case, > > I could provide "structural" and stable properties inside an application > > bundle, changing properties could be resolved by a ConfiguratorPlugin > > (the source can be easier to administrate, no PIDs) and secrets by a > > ConfigurationPlugin. Does that make sense? > > Clement > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday 8 October 2019 20:41, Jürgen Albert via osgi-dev > > osgi-dev@mail.osgi.org wrote: > > > > > Hi Clement, > > > we have discussed this problem you have at a OSGi meeting and Carsten > > > Ziegler implemented something that goes beyond the Spec, that might > > > help you I assume here that you are using the Felix ConfigAdmin. See: > > > https://issues.apache.org/jira/browse/FELIX-6059 > > > You have to possibilities: > > > > > > 1. The ConfigAdmin will be registered with a property config.plugins, > > > that names all ConfigurationPlugins that serve a property > > > config.plugin.id. Thus register your plugin with e.g. > > > config.plugin.id=my.id. Add a mandatory Service reference for the > > > Config Admin with a target filter like (config.plugins=my.id) in the > > > service that needs configuration. With this your Service will be > > > activated after the ConfigAdmin knows about you plugin and handles the > > > properties accordingly. > > > > > > 2. If you start your runtime with a framework property > > > felix.cm.config.plugins=my.id1,my.id2 the ConfigAdmin will not become > > > active and registered until the a Plugin with config.plugin.id=my.id1 > > > and config.plugin.id=my.id2 is available. > > > > > > > > > I hope this helps, > > > Jürgen. > > > Am 08/10/2019 um 16:27 schrieb Tim Ward via osgi-dev: > > > > > > > > My question is, how can I tell to the Configurator bundle to not > &g
Re: [osgi-dev] Configurator resources that depend on a ConfigurationPlugin
Thanks for your help, Jürgen and Tim's solutions could meet my needs, but as BJ said values are replaced each time the configuration is delivered to the target and as I understand not saved. Maybe it is appropriate just for password and secrets. My application configurations generally contain "structural" properties (eg; myreference.target=), stable properties (eg; url.to.publickey=), properties that change according to the environment (cache.policy=) and secret properties. It would be nice if the configurator could in addition handle placeholders, if it was the case, I could provide "structural" and stable properties inside an application bundle, changing properties could be resolved by a ConfiguratorPlugin (the source can be easier to administrate, no PIDs) and secrets by a ConfigurationPlugin. Does that make sense? Clement ‐‐‐ Original Message ‐‐‐ On Tuesday 8 October 2019 20:41, Jürgen Albert via osgi-dev wrote: > Hi Clement, > > we have discussed this problem you have at a OSGi meeting and Carsten Ziegler > implemented something that goes beyond the Spec, that might help you I assume > here that you are using the Felix ConfigAdmin. See: > https://issues.apache.org/jira/browse/FELIX-6059 > > You have to possibilities: > 1. The ConfigAdmin will be registered with a property config.plugins, that > names all ConfigurationPlugins that serve a property config.plugin.id. Thus > register your plugin with e.g. config.plugin.id=my.id. Add a mandatory > Service reference for the Config Admin with a target filter like > (config.plugins=my.id) in the service that needs configuration. With this > your Service will be activated after the ConfigAdmin knows about you plugin > and handles the properties accordingly. > > 2. If you start your runtime with a framework property > felix.cm.config.plugins=my.id1,my.id2 the ConfigAdmin will not become active > and registered until the a Plugin with config.plugin.id=my.id1 and > config.plugin.id=my.id2 is available. > > I hope this helps, > > Jürgen. > > Am 08/10/2019 um 16:27 schrieb Tim Ward via osgi-dev: > >>> My question is, how can I tell to the Configurator bundle to not process >>> resources that contains placeholder until my ConfigurationPlugin is up? >> >> There are ways that you could attempt to do this, however they’re all >> inelegant and error prone. What would make more sense would be for the >> ConfigurationPlugin to detect the existing configurations which contain >> placeholders at startup and trigger an update for them. This will cause the >> configuration to be re-delivered, including any necessary configuration >> plugin execution. >> >> In general you are better off trying to make things ordering independent >> rather than to control the order that things happen in. The result is a much >> more flexible and stable system. >> >> Best Regards, >> >> Tim >> >>> On 8 Oct 2019, at 12:54, BJ Hargrave via osgi-dev >>> wrote: >>> >>> Configuration Plugins mutate configuration data each time it is delivered >>> to a configuration target. So the Configuration Plugin must be active >>> before any configuration targets which care about the mutated configuration >>> data. >>> >>> So this is orthogonal to Configurator which is about putting configuration >>> data in the CM configuration data store. >>> -- >>> >>> 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: "Clément Delgrange via osgi-dev" >>>> Sent by: osgi-dev-boun...@mail.osgi.org >>>> To: OSGi Developer Mail List >>>> Cc: >>>> Subject: [EXTERNAL] [osgi-dev] Configurator resources that depend on a >>>> ConfigurationPlugin >>>> Date: Tue, Oct 8, 2019 06:08 >>>> >>>> Hi all, >>>> >>>> I have a question regarding the Configurator and the ConfigurationPlugin >>>> spec. I would like to provision my application with configurations as I do >>>> with my the bundles, for this the Configurator seems perfect. But, the >>>> values inside my configurations could be different depending of the >>>> environment (dev, beta, prod, ...) and my configurations may contain >>>> sensitive data that I don't want in my Git repo. In this case I think I >>>> could provide a ConfigurationPlugin which will replace
[osgi-dev] Configurator resources that depend on a ConfigurationPlugin
Hi all, I have a question regarding the Configurator and the ConfigurationPlugin spec. I would like to provision my application with configurations as I do with my the bundles, for this the Configurator seems perfect. But, the values inside my configurations could be different depending of the environment (dev, beta, prod, ...) and my configurations may contain sensitive data that I don't want in my Git repo. In this case I think I could provide a ConfigurationPlugin which will replace placeholders with data coming from a database. My question is, how can I tell to the Configurator bundle to not process resources that contains placeholder until my ConfigurationPlugin is up? Thanks, Clément Delgrange.___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Help with the OSGi Converter
Thanks Ray,
Indeed, it works now and the method I pointed out was changed. Maybe an EnRoute
index poms should be added to include the current best quality bundles?! It
could help new newcomers to get bundles with less bugs.
Clément.
‐‐‐ Original Message ‐‐‐
On Friday 17 May 2019 19:52, Raymond Auge wrote:
> I don't have a concrete answer since I'd have to also debug. However, I can
> make a suggestion to perhaps try:
>
>
> org.apache.felix
> org.apache.felix.converter
> 1.0.8
>
> which is Apache Felix implementation of the osgi converter spec. What you'll
> find is that it's moving along a little faster with bug fixes. It's a drop in
> replacement.
>
> It also means that Apache Felix mail list may have a few more bodies
> monitoring it that have deep knowledge of the implementation details.
>
> Also note that Apache Felix converter implementation was the seed code for
> the official OSGi artifact.
>
> - Ray
>
> On Fri, May 17, 2019 at 12:43 PM Clément Delgrange via osgi-dev
> wrote:
>
>> Hi,
>>
>> I use the OSGi Converter to convert a proxy of an Interface to a Map and I
>> get an exception:
>>
>> org.osgi.util.converter.ConversionException: Cannot convert null to
>> interface java.util.Map
>> at
>> org.osgi.util.converter.ConvertingImpl.convertToMapType(ConvertingImpl.java:650)
>> at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:187)
>> at
>> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
>> at
>> org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:144)
>> ...
>>
>> I don't know if it is a bug or not? Here is what I am doing:
>>
>> 1- I have two interfaces:
>> public interface ParentType
>> {
>> String test();
>> }
>>
>> public interface ChildType extends ParentType
>> {
>> // Marker interface
>> }
>>
>> 2- I instantiate my proxy:
>> ChildType proxy = createProxy(); // My proxy return a constant "test" when
>> test() is invoked.
>>
>> 3- I try to convert and get the exception:
>> converter.convert(proxy).sourceAs(ChildType.class).to(new
>> TypeReference>() {/**/}));
>>
>> If I add a method to ChildType ('String qq();') the conversion works.
>>
>> Here is what I have found while debugging:
>> 1- The converter tries to determine if my source is a map type
>> (ConvertingImpl.isMapType)
>> 2- For this, it calls the method ConvertingImpl.getInterfaces0(Class< ? >
>> cls) with cls=ChildType.class. For ChildType be considered as a map type,
>> this method should return a set of interfaces that contains ParentType.class
>> (which has public method) but it doesn't. Indeed, implemented/extended
>> interfaces are added to the result only if `cls` is not an interface, I
>> don't really understand why?
>>
>> Sorry if this mail is a bit obscure and specific, I didn't find an other
>> place to ask...
>>
>> You can find a repository demonstrating the issue here:
>> https://github.com/cdelg/demo-converter-bug-or-not
>>
>> Thanks for help.
>>
>> Clément.
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> --
> [Raymond Augé](http://www.liferay.com/web/raymond.auge/profile) (@rotty3000)
> Senior Software Architect [Liferay, Inc.](http://www.liferay.com) (@Liferay)
> Board Member & EEG Co-Chair, [OSGi Alliance](http://osgi.org) (@OSGiAlliance)___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Help with the OSGi Converter
Hi,
I use the OSGi Converter to convert a proxy of an Interface to a Map and I get
an exception:
org.osgi.util.converter.ConversionException: Cannot convert null to interface
java.util.Map
at
org.osgi.util.converter.ConvertingImpl.convertToMapType(ConvertingImpl.java:650)
at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:187)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:176)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:144)
...
I don't know if it is a bug or not? Here is what I am doing:
1- I have two interfaces:
public interface ParentType
{
String test();
}
public interface ChildType extends ParentType
{
// Marker interface
}
2- I instantiate my proxy:
ChildType proxy = createProxy(); // My proxy return a constant "test" when
test() is invoked.
3- I try to convert and get the exception:
converter.convert(proxy).sourceAs(ChildType.class).to(new
TypeReference>() {/**/}));
If I add a method to ChildType ('String qq();') the conversion works.
Here is what I have found while debugging:
1- The converter tries to determine if my source is a map type
(ConvertingImpl.isMapType)
2- For this, it calls the method ConvertingImpl.getInterfaces0(Class< ? > cls)
with cls=ChildType.class. For ChildType be considered as a map type, this
method should return a set of interfaces that contains ParentType.class (which
has public method) but it doesn't. Indeed, implemented/extended interfaces are
added to the result only if `cls` is not an interface, I don't really
understand why?
Sorry if this mail is a bit obscure and specific, I didn't find an other place
to ask...
You can find a repository demonstrating the issue here:
https://github.com/cdelg/demo-converter-bug-or-not
Thanks for help.
Clément.___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] PushStream Question
Thanks Tim for your help, I will raise the bug.
--
Clément Delgrange
‐‐‐ Original Message ‐‐‐
On Monday 10 December 2018 12:52, Tim Ward wrote:
> Hi Clément,
>
> You should raise a bug about the JavaDoc/implementation inconsistency in the
> OSGi bugzilla. The StackOverflow question is now answered, hopefully to your
> satisfaction.
>
> Best Regards,
>
> Tim
>
>> On 9 Dec 2018, at 21:35, Clément Delgrange via osgi-dev
>> wrote:
>>
>> Hi all,
>>
>> I have two questions related to the OSGi PushStream implementation. The
>> first one is on
>> [Stackoverflow.com](https://stackoverflow.com/questions/53692861/osgi-pushstream-is-slow);
>> the second is the publish method of the SimplePushEventSource says that it
>> throws a IllegalStateException if the source is closed:
>>
>>> /**
>>> * Asynchronously publish an event to this stream and all connected
>>> * {@link PushEventConsumer} instances. When this method returns there is no
>>> * guarantee that all consumers have been notified. Events published by a
>>> * single thread will maintain their relative ordering, however they may be
>>> * interleaved with events from other threads.
>>> *
>>> * @param t
>>> * @throws IllegalStateException if the source is closed
>>> */
>>> void publish(T t);
>>
>> But in the implementation it only returns:
>>
>>> @Override
>>> public void publish(T t) {
>>> enqueueEvent(PushEvent.data(t));
>>> }
>>>
>>> private void enqueueEvent(PushEvent event) {
>>> synchronized (lock) {
>>> if (closed || connected.isEmpty()) {
>>> return;
>>> }
>>> }
>>>
>>> try {
>>> queuePolicy.doOffer(queue, event);
>>> boolean start;
>>> synchronized (lock) {
>>> start = !waitForFinishes && semaphore.tryAcquire();
>>>}
>>>if (start) {
>>> startWorker();
>>>}
>>>} catch (Exception e) {
>>>close(PushEvent.error(e));
>>>throw new IllegalStateException("The queue policy threw an
>>> exception", e);
>>> }
>>> }
>>
>> When the exception is thrown? I have tested with the following code:
>>
>>> source.close();
>>> source.publish( 1 );
>>
>> and effectively it only returns.
>>
>> Thanks
>> --
>> Clément Delgrange
>>
>> ___
>> 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
[osgi-dev] PushStream Question
Hi all,
I have two questions related to the OSGi PushStream implementation. The first
one is on
[Stackoverflow.com](https://stackoverflow.com/questions/53692861/osgi-pushstream-is-slow);
the second is the publish method of the SimplePushEventSource says that it
throws a IllegalStateException if the source is closed:
> /**
> * Asynchronously publish an event to this stream and all connected
> * {@link PushEventConsumer} instances. When this method returns there is no
> * guarantee that all consumers have been notified. Events published by a
> * single thread will maintain their relative ordering, however they may be
> * interleaved with events from other threads.
> *
> * @param t
> * @throws IllegalStateException if the source is closed
> */
> void publish(T t);
But in the implementation it only returns:
> @Override
> public void publish(T t) {
> enqueueEvent(PushEvent.data(t));
> }
>
> private void enqueueEvent(PushEvent event) {
> synchronized (lock) {
> if (closed || connected.isEmpty()) {
> return;
> }
> }
>
> try {
> queuePolicy.doOffer(queue, event);
> boolean start;
> synchronized (lock) {
> start = !waitForFinishes && semaphore.tryAcquire();
>}
>if (start) {
> startWorker();
>}
>} catch (Exception e) {
>close(PushEvent.error(e));
>throw new IllegalStateException("The queue policy threw an exception",
> e);
> }
> }
When the exception is thrown? I have tested with the following code:
> source.close();
> source.publish( 1 );
and effectively it only returns.
Thanks
--
Clément Delgrange ___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] enRoute JPA example questions
Thanks for the link! -- Clément Delgrange ‐‐‐ Original Message ‐‐‐ On Friday 7 December 2018 13:08, Christian Schneider wrote: > A good example for the usage of DTOs is: > > http://javadox.com/org.osgi/osgi.cmpn/6.0.0/org/osgi/service/component/runtime/ServiceComponentRuntime.html > > Christian > > Am Fr., 7. Dez. 2018 um 12:07 Uhr schrieb Clément Delgrange via osgi-dev > : > >> Hi, thanks for your response. >> >>> As I mention above, it would be very bad for the DAO to use entity types in >>> its API as this would force the implementation decision... >> >> I agree, I would not replace API parameters with entity types I meant >> replacing entity types with DTOs and API parameters with plain Interface or >> Classes. >> >>> The REST API is actually not coupled to the DTO representation... >> >> Yes indeed. >> >>> It’s quite the opposite - the DTOs are the public inter-bundle >>> communication data. They are used this way in a lot of OSGi specifications. >> >> I looked at the R7 osgi.cmpn in the org.osgi.service.* packages but I did >> not see services using DTOs in that way, maybe have you a link? Or better a >> realistic project that use DTOs for service parameters and return type?. >> >> Your response clarify a the way enRoute proposes to use DTOs but it is still >> hard to now when to use them. For example, if the microservice example >> change: now the REST service does not call the DAO layer directly but a >> PersonManager service that will send events, call other services, ... and >> finally call the DAO layer. The PersonManager service has almost the same >> methods than the PersonDao service, do you use DTOs for the PersonManager >> service? In this way DTOs seem less flexible than interfaces for >> parameters/return types, if later we want to add a `getFullName` or a method >> to filter Addresses? As mentioned in the tutorial, DTOs are not immutable or >> thread safe, does that mean each time you call a service you copy them? >> >> Clément. >> -- >> Clément Delgrange >> >> ‐‐‐ Original Message ‐‐‐ >> On Friday, December 7, 2018 11:09 AM, Tim Ward wrote: >> >>> Hi Clément, >>> >>>> - The de-coupling is not the fact that they are DTOs? If the API had >>>> defined Interfaces or Classes the de-coupling would be the same. >>> >>> In this case the decoupling is from the data model. If the DTO types were >>> JPA entities (i.e. they had JPA annotations on them) then everyone would be >>> coupled to the JPA data model, and in turn, the database. You are correct >>> that the types don’t need to be DTOs for this to be the case, however DTOs >>> are a good choice because they force you to treat the exchanged objects as >>> pure data, rather than an implementation specific behaviour or mapping. >>> Perhaps a slightly better wording would be "Because of the de-coupling >>> provided by the [DTO](https://enroute.osgi.org/FAQ/420-dtos.html) package, >>> all we need do is re-implement dao-impl…” >>> >>>> - I understand the usage of DTOs for the REST service (as data are >>>> leaving/coming) but not for the *DAO services API. The actual data leaving >>>> the system are the *Entity classes in the implementation bundle (so the >>>> transferable objects are converted into other transferable objects!). >>> >>> As I mention above, it would be very bad for the DAO to use entity types in >>> its API as this would force the implementation decision. The implementing >>> bundle should be free to use JDBC, JPA, NoSQL or whatever it wants to store >>> and retrieve values. The moment that you start talking about Entity Classes >>> you’re already most of the way to an ORM implementation, which is one heck >>> of an implementation internals leak. >>> >>>> - Also the fact that the DTOs are exported and used in the service >>>> contract in the API bundle, the REST-API (and so the clients) is coupled >>>> to the internal representation of the Java application. >>> >>> The REST API is actually not coupled to the DTO representation - the REST >>> service implementation could do whatever transformation it chose >>> internally. For simplicity we have chosen to keep the REST responses close >>> to the DTOs, but we could have quite easily changed all of the field names >>> in the JSON. Again, the OSGi implementations communicate using an API, but >>
Re: [osgi-dev] enRoute JPA example questions
dle using the framework - the OSGi enRoute micro service example is > a great place to look. The JPA entities are internal to the JPA > implementation of the Data Access Service, as it is the only user bundle that > knows that JPA is being used. > > Best Regards, > > Tim > >> On 6 Dec 2018, at 19:30, Clément Delgrange via osgi-dev >> wrote: >> >> Hi, >> >> I have some questions regarding the OSGi enRoute microservice example and >> the usage of DTOs. >> ([enroute-tutorial-jpa](https://enroute.osgi.org/tutorial/032-tutorial_microservice-jpa.html), >> [enroute-dto](https://enroute.osgi.org/FAQ/420-dtos.html)). >> >> I think I understand the purpose of DTOs (easy to write, easy to process, >> useful when data leave the system) but their usage in the JPA example is not >> clear: >> >>> Because of the de-coupling provided by the >>> [DTOs](https://enroute.osgi.org/FAQ/420-dtos.html)’s, all we need do is >>> re-implement dao-impl... >> >> - The de-coupling is not the fact that they are DTOs? If the API had defined >> Interfaces or Classes the de-coupling would be the same. >> - I understand the usage of DTOs for the REST service (as data are >> leaving/coming) but not for the *DAO services API. The actual data leaving >> the system are the *Entity classes in the implementation bundle (so the >> transferable objects are converted into other transferable objects!). >> - Also the fact that the DTOs are exported and used in the service contract >> in the API bundle, the REST-API (and so the clients) is coupled to the >> internal representation of the Java application. >> >> I thought the DTOs was more data-api specific to a provider bundle, such as >> : some-framework-rest-provider (with private DTOs) --adapt--> Java >> application (with domain interface/class) --adapt--> jpa-dao-provider (with >> private DTOs) . >> >> If in contrary the purpose of the DTOs is to have one consistent data >> representation which evolves as soon as it is required by one of the system >> (rest, java application, database-schema), how to deal with framework >> specific annotations? >> >> I hope I was clear enough! >> Thanks. >> -- >> Clément Delgrange >> >> ___ >> 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
[osgi-dev] enRoute JPA example questions
Hi, I have some questions regarding the OSGi enRoute microservice example and the usage of DTOs. ([enroute-tutorial-jpa](https://enroute.osgi.org/tutorial/032-tutorial_microservice-jpa.html), [enroute-dto](https://enroute.osgi.org/FAQ/420-dtos.html)). I think I understand the purpose of DTOs (easy to write, easy to process, useful when data leave the system) but their usage in the JPA example is not clear: > Because of the de-coupling provided by the > [DTOs](https://enroute.osgi.org/FAQ/420-dtos.html)’s, all we need do is > re-implement dao-impl... - The de-coupling is not the fact that they are DTOs? If the API had defined Interfaces or Classes the de-coupling would be the same. - I understand the usage of DTOs for the REST service (as data are leaving/coming) but not for the *DAO services API. The actual data leaving the system are the *Entity classes in the implementation bundle (so the transferable objects are converted into other transferable objects!). - Also the fact that the DTOs are exported and used in the service contract in the API bundle, the REST-API (and so the clients) is coupled to the internal representation of the Java application. I thought the DTOs was more data-api specific to a provider bundle, such as : some-framework-rest-provider (with private DTOs) --adapt--> Java application (with domain interface/class) --adapt--> jpa-dao-provider (with private DTOs) . If in contrary the purpose of the DTOs is to have one consistent data representation which evolves as soon as it is required by one of the system (rest, java application, database-schema), how to deal with framework specific annotations? I hope I was clear enough! Thanks. -- Clément Delgrange ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] How to specify a requirements on JSR-353 (Json) implementation
Thanks! I'll try with geronimo. -- Clément Delgrange ‐‐‐ Original Message ‐‐‐ On Tuesday, November 20, 2018 3:37 PM, Raymond Auge wrote: > If you use this API dependency instead: > > > org.apache.geronimo.specs > geronimo-json_1.1_spec > 1.1 > > > it will do exactly what you want. > (make sure you also have a recent Aries SpiFly in your runtime dependencies > somewhere) > > - Ray > > On Tue, Nov 20, 2018 at 8:26 AM Clément Delgrange via osgi-dev > wrote: > >> Hi, >> >> I have a service that uses the Json API( javax.json.*). My project has a >> compile dependency on : >> >> >> org.apache.servicemix.specs >> org.apache.servicemix.specs.json-api-1.1 >> 2.9.0 >> >> >> and a test dependency on: >> >> >> org.apache.johnzon >> johnzon-core >> 1.1.0 >> >> >> In another project, when I resolve the bundle that contains my service, the >> johnzon-core bundle is not resolved and everything looks OK until runtime. I >> would like to add an annotation on the service that depends on the Json API >> (@Capability) but I don't know which namespace I should use for this? (The >> johnzon-core does not provide any capability except package exports while >> its description says it is an implementation of JSR-353) >> >> A similar service can be found in the OSGI enRoute example at >> https://github.com/osgi/osgi.enroute/blob/master/examples/microservice/rest-service/pom.xml >> >> Thanks! >> -- >> Clément Delgrange >> >> ___ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > -- > [Raymond Augé](http://www.liferay.com/web/raymond.auge/profile) (@rotty3000) > Senior Software Architect [Liferay, Inc.](http://www.liferay.com) (@Liferay) > Board Member & EEG Co-Chair, [OSGi Alliance](http://osgi.org) (@OSGiAlliance)___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] How to specify a requirements on JSR-353 (Json) implementation
Hi, I have a service that uses the Json API( javax.json.*). My project has a compile dependency on : org.apache.servicemix.specs org.apache.servicemix.specs.json-api-1.1 2.9.0 and a test dependency on: org.apache.johnzon johnzon-core 1.1.0 In another project, when I resolve the bundle that contains my service, the johnzon-core bundle is not resolved and everything looks OK until runtime. I would like to add an annotation on the service that depends on the Json API (@Capability) but I don't know which namespace I should use for this? (The johnzon-core does not provide any capability except package exports while its description says it is an implementation of JSR-353) A similar service can be found in the OSGI enRoute example at https://github.com/osgi/osgi.enroute/blob/master/examples/microservice/rest-service/pom.xml Thanks! -- Clément Delgrange ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Re : Service binding order
Hi David,
From the spec I read:
> 112.5.10 Binding Services
>
> When binding services, the references are processed in the order in which
> they are specified in the component description. That is, target services
> from the first specified reference are bound before services from the next
> specified reference.
So, I understand that if your executor comes before yours items reference in
the component declaration you have the garantee that the executor will be
bounded before your items.
Cheers,
Clément.
Message d'origine
On 18 juil. 2018 à 00:16, David Leangen via osgi-dev a écrit :
> Hi!
>
> I have a component that acts a bit like a whiteboard provider. It looks
> something like this:
>
> public class MyWhiteboard
> {
> boolean isActive;
>
> @Reference MyExecutor executor; // Required service to execute on an Item
>
> @Reference(multiple/dynamic)
> void bindItem( Item item )
> {
> if (isActivated)
> // add the Item
> else
> // Store the item to be added once this component is activated
> }
>
> void unbindItem( Item item )
> {
> // Remove the item
> }
>
> @Activate
> void activate()
> {
> // execute non-processed Items
> isActivate = true;
> }
> }
>
> The MyExecutor must be present before an Item can be processed, but there is
> no guarantee as to the binding order. All I can think of doing is ensuring
> that the Component is Activated before processing.
>
> My question is: is there a more elegant / simpler / less error prone way of
> accomplishing this?
>
> Thanks!
> =David
>
> ___
> 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] Multi-Tenancy with OSGI
ant selection logic but it will > work only with prototype scope (service lookup upon each request). > Cheers, > Łukasz Dywicki > >> On 1 Jul 2018, at 21:03, David Leangen via osgi-dev osgi-dev@mail.osgi.org >> wrote: >> Hi Clément, >> We ended up doing this via ServiceFactory. >> A service is either “tenant-aware” (meaning that the tenant logic is built >> into the service), or more commonly “tenant-unaware” (meaning that it’s like >> you write below: the service has no knowledge of the tenant). For those that >> are tenant-aware, we only need one instance (assuming it is a singleton). >> For those that are not tenant-aware, we need once instance per tenant. All >> we need to do for a tenant-aware service is add the “factory” property to >> the component. The FactoryService listens for both tenants and tenant-aware >> services, and will instantiate a tenant-aware service as required. This >> allows us to dynamically adapt if a new tenant is registered. >> This approach has also allowed us to customize services for a specific >> tenant as required, which was an unexpected bonus. >> All services that can be shared are shared, which means that I think (have >> not actually calculated) that we are using computing resources efficiently. >> In any case, this has been working well for us so far. >> Cheers, >> =David >> >>> On Jul 2, 2018, at 2:11, Clément Delgrange via osgi-dev >>> osgi-dev@mail.osgi.org wrote: >>> Hi, >>> What is the way to achieve multi-tenancy with OSGI service. I would like to >>> design my API without a tenant context per method to concentrate on the >>> functional part, but also have an OSGI instance which could be scaled up. I >>> was thinking to let the service implementation decides if the service can >>> be shared between multiple tenants or not, and in this later case rely on a >>> standard way to bound service instances specifically for a tenant. Does >>> configuration admin can help with this? >>> For example, a service could be configured with multiple PIDs, one for >>> shared configuration and one factory configuration for tenant specific >>> configuration and then filter references in component, does that could >>> work? Is there some good practice for multi tenancy in OSGI? >>> Thanks, >>> Clément. >>> 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___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] Multi-Tenancy with OSGI
Hi, What is the way to achieve multi-tenancy with OSGI service. I would like to design my API without a tenant context per method to concentrate on the functional part, but also have an OSGI instance which could be scaled up. I was thinking to let the service implementation decides if the service can be shared between multiple tenants or not, and in this later case rely on a standard way to bound service instances specifically for a tenant. Does configuration admin can help with this? For example, a service could be configured with multiple PIDs, one for shared configuration and one factory configuration for tenant specific configuration and then filter references in component, does that could work? Is there some good practice for multi tenancy in OSGI? Thanks, Clément.___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
[osgi-dev] OSGI statistic
Hi, I have some general questions related to OSGI. I was wondering if at the OSGI alliance you have recent statistics on the use of OSGI in companies. Especially, what proportion they use of the core and the enterprise specifications, the numbers of concerned projects, if they are seeking for OSGI skilled employees, ... I found that few open source projects are actually using OSGI, or it is often to allow users to run their software into an OSGI container leaving aside services such as EventAdmin, ConfigurationAdmin, DS, ... . Their first argument for this is to be able to keep their application compatible with any runtime environments (a good example could be Neo4j). Are you agree with that? Is it the same thing for companies? Are you aware of projects that aim to make OSGI projects easier to use in any environments when they use some of the enterprise specifications? Best Regards, Clement.___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
