Thanks Scott. Thanks for the detailed explanation, it really helps me and I think also the community a lot.
Sorry for coming back late, but I am really busy with some other things on hand recently. I personally think OSGIRegistry can be a good choice to enrich the Dubbo ecosystem. I would recommend the extension exists as an independent project in Apache[1] first, just like dubbo-spring-boot-project[2]. The community can help to transfer the project to apache organization once it’s done and you decide to donate. As for OSGI bundle I am not sure if Dubbo needs that kind of deployment or distribution form, we need further discussion in the mailing-list. What do others think, especially those familiar with OSGI? 1. http://github.com/apache 2. https://github.com/apache/dubbo-spring-boot-project Jun > On Sep 3, 2019, at 7:58 AM, Scott Lewis <[email protected]> wrote: > > Hi Jun, > > On 9/1/2019 10:29 PM, Scott Lewis wrote: >> <stuff delected> > >> Yes both of these use cases are supported. As an example of 1: during >> testing of the DubboProvider I exported a DemoService instances as an OSGi >> Remote Service. Since it was exported with the Dubbo protocol, it >> can/could be accessed by either an OSGi-based client (as per the examples in >> the DubboProvider...i.e. 2) AND I tested access to it via a Java-only client >> (from dubbo-demo-api-consumer). What this means is that such a service can >> be accessed by any consumer (OSGi or not) that uses the dubbo protocol (both >> 1 and 2). > > To provide an example of this, I created this java project [1]. It's a > DemoService consumer that is Java-only (similar to your own > dubbo-demo-api-consumer except for how the dubbo url is discovered), but it > can use/call the DemoService exported by the OSGi RS impl [2]. > > Scott > > [1] > https://github.com/ECF/DubboProvider/tree/master/examples/ecf.example.demo.consumer > > [2] > https://github.com/ECF/DubboProvider/tree/master/examples/org.eclipse.ecf.examples.provider.dubbo.demo.impl > > >
