Par a talk with Michael V. at the Seattle conference, re-popping this subject. From what Tom P. is saying, order of loading between a bundle that needs to invoke an RPC on a different bundle, is guaranteed using <rpc-service> in BP.
From: Sela, Guy Sent: Tuesday, July 19, 2016 9:06 AM To: 'Tom Pantelis' <tompante...@gmail.com> Cc: controller-dev@lists.opendaylight.org; mdsal-...@lists.opendaylight.org; odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org> Subject: RE: [controller-dev] [lispflowmapping-dev] LispMappingService as an OSGi Service Thanks So, just to makes things clear: 1) RPC consumers should always use “rpc-service” in BP, if they want to guarantee that the RpcProvider is already loaded. 2) Just injecting the RpcProviderRegistry via BP and getting the “IExample” reference via code, will guarantee nothing about the RpcProvider. Correct? From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: Monday, July 18, 2016 3:01 PM To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> Cc: controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>; mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org>; odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>> Subject: Re: [controller-dev] [lispflowmapping-dev] LispMappingService as an OSGi Service With blueprint, the "rpc-service" extension asynchronously waits for a backing RPC implementation and blocks BP container startup in the same way as OSGi service dependencies. On Sun, Jul 17, 2016 at 4:02 AM, Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> wrote: +Adding controller-dev list I will summarize my question: Bundle A is a consumer of an RPC interface called IExample. Bundle B (impl) is the provider of the RPC. Bundle C (int) is where IExample is actually declared. Bundle A depends on Bundle C. What ensures me that Bundle B has already finished loading before Bundle A can invoke RPCs? Activator/Blueprint wise, Bundle A only “requests” injection of the RPCRegistry, and doesn’t requests Bundle B or C. From: Sela, Guy Sent: Monday, July 11, 2016 12:49 PM To: Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco) <rova...@cisco.com<mailto:rova...@cisco.com>>; mdsal-...@lists.opendaylight.org<mailto:mdsal-...@lists.opendaylight.org> Cc: odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>>; Lori Jakab <lorand.jakab+...@gmail.com<mailto:lorand.jakab%2b...@gmail.com>> Subject: RE: [lispflowmapping-dev] LispMappingService as an OSGi Service Is there any documentation about “order of loading” control when using RpcRegistry ? From: lispflowmapping-dev-boun...@lists.opendaylight.org<mailto:lispflowmapping-dev-boun...@lists.opendaylight.org> [mailto:lispflowmapping-dev-boun...@lists.opendaylight.org] On Behalf Of Sela, Guy Sent: Friday, July 08, 2016 12:34 AM To: Lori Jakab <lorand.jakab+...@gmail.com<mailto:lorand.jakab+...@gmail.com>> Cc: Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco) <rova...@cisco.com<mailto:rova...@cisco.com>>; odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>> Subject: Re: [lispflowmapping-dev] LispMappingService as an OSGi Service “order of loading” makes sense. But actually it leads me to a more basic question. If the RpcRegistry doesn’t promise you “order of loading”, so how is it solved in all of ODL? Let’s say Bundle A is a consumer of an Rpc called IExample. Bundle B is the provider of the IExample Rpc. In the init process of Bundle A, it asks the RpcRegistry for a reference to the IExample interface. If there is nothing that takes care of making sure that Bundle B is already loaded, how can Bundle A know when is it okay to start invoking the RPCs? From: lispflowmapping-dev-boun...@lists.opendaylight.org<mailto:lispflowmapping-dev-boun...@lists.opendaylight.org> [mailto:lispflowmapping-dev-boun...@lists.opendaylight.org] On Behalf Of Lori Jakab Sent: Thursday, July 07, 2016 6:17 PM To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> Cc: odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>> Subject: Re: [lispflowmapping-dev] LispMappingService as an OSGi Service Hi Guy, On Thu, Jul 7, 2016 at 2:21 AM, Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> wrote: Hi Vina, What you just illustrated is technically correct. I am talking about a more high level concept. Even since we moved to MD-SAL, projects are supposed to communicate with each other via MD-SAL. This means RPCs, Notifications, and DCNs. So, theoretically, there is no need to even have OSGi Services anymore. Indeed, for inter-project communication OSGi services are not strictly necessary. The only services that actually register in the OSGi Registry are: DataBroker(for datastore), RpcRegistry, and Notification Service. Whenever I see a project that exposes Services in the OSGi Registry I want to understand the reason behind it. Dependency injection is a reasonable reason for doing that, but only if it is aimed to inner project implementation. If you put an OSGi Service in the OSGI Registry and expect other projects to find it and call it, this means you diverted from the ODL way of bundle communication. The reason is not for other projects to find the API exposed through an interface and call it, it is to signal that a certain service has become available. There are services that require other services to be loaded before them, and for some projects service load order is critical, and to the best of my knowledge, that's why we still use the OSGi registry. The lispflowmapping project is certainly no looking for services in the OSGi registry, for calling the API exposed. Although if for performance reasons we may see an advantage of avoiding the MD-SAL for inter-service communication, we still might take advantage of direct Java API calls. HTH, -Lori This is my understanding of the picture. What do you think? Regards, Guy From: Vina Ermagan (vermagan) [mailto:verma...@cisco.com<mailto:verma...@cisco.com>] Sent: Wednesday, July 06, 2016 2:02 AM To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>>; Lori Jakab <lorand.jakab+...@gmail.com<mailto:lorand.jakab%2b...@gmail.com>> Cc: odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>> Subject: Re: [lispflowmapping-dev] LispMappingService as an OSGi Service Hi Guy, What do you mean exactly by MD-SAL registry? The main way of injecting services was via Activators for the first couple of releases. Then Activators were deprecated, and the community switched to Config SubSystem up until and including Beryllium. For Boron however, the community decided to move to blueprints. So all the CSS plumbing has been removed and we use the blueprints for service/dependency injection in Boron. This last switch happened a few weeks ago in a single patch. Hope this helps. Best, Vina From: <lispflowmapping-dev-boun...@lists.opendaylight.org<mailto:lispflowmapping-dev-boun...@lists.opendaylight.org>> on behalf of "Sela, Guy" <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> Date: Friday, July 1, 2016 at 8:37 AM To: Lori Jakab <lorand.jakab+...@gmail.com<mailto:lorand.jakab+...@gmail.com>> Cc: odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>> Subject: Re: [lispflowmapping-dev] LispMappingService as an OSGi Service Hi Lori, So if the API of the LispMappingService is RPCs and Notifications, why would you register it an in the OSGi Registry? You need to register it in the MD-SAL’s RPC Registry, and then have the consumer get injected only with the RPC Registry, and get the ILispMappingService from that. From: lorand.ja...@gmail.com<mailto:lorand.ja...@gmail.com> [mailto:lorand.ja...@gmail.com] On Behalf Of Lori Jakab Sent: Friday, July 01, 2016 4:41 PM To: Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> Cc: odl lispflowmapping dev <lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org>> Subject: Re: [lispflowmapping-dev] LispMappingService as an OSGi Service Hi, On Fri, Jul 1, 2016 at 2:04 AM, Sela, Guy <guy.s...@hpe.com<mailto:guy.s...@hpe.com>> wrote: Hi, General question about MD-SAL RPC Registry vs. OSGi Registry. I’m just trying to get my head straight on these subjects. Since we moved to MD-SAL, modules “should” talk to each other using MD-SAL(RPCs, Notifications, DataTree). And this is what we're doing, we use RPCs, Notifications and the DataTree quite heavily, and have very few direct Java calls between modules. I saw that you chose to register LispMappingService in the OSGI registry. I just want to make sure I understand the reasons: 1) You don’t want it to be in the MD-SAL registry because you don’t won’t other modules in ODL to interact with it. It is part of your inner implementation. No, this is not the reason for us, we do define and notifications and RPCs. 2) You still register it in the OSGi registry as an OSGi Service instead of just doing “direct Java calls” to the bundle, because you want the ability to change the implementing bundle without affecting the consuming bundle. The main reason is dependency injection. We used the config subsystem for this initially. We now switched to blueprints, as there were discussions at the last Developer Design Forum on their advantages. The blueprint implementation from ODL has some additional features implemented to achieve feature parity with the config subsystem (it's not fully there yet, but close). I assume these are the reasons. Could bullet 2 be achieved without turning it to an OSGi service? What are the downsides of the LispMappingService being an OSGi service. AFAIK, even while we used the config subsystem, it was still registered as an OSGi service. From the top of my head the answer is no. Even if you split the solution to “implementation” bundle and “interface” bundle, and have the “consumer” bundle depend only on the “interface” bundle, what part of the code would be in charge for the injection of the current “implementation” bundle to the “consumer” bundle. By registering it in the OSGi registry, and declaring it in the blueprint, you let OSGi do the injection for you. Yes. If we would use standard JSE, we would need reflection or some kind of Factory design pattern that will also take care of “order of instantiation” between implementor and consumer. I'm not familiar enough with JSE to answer this question. I hope I was able to clear some of things up a bit. Regards, -Lori Am I correct? Thanks, Guy Sela _______________________________________________ lispflowmapping-dev mailing list lispflowmapping-...@lists.opendaylight.org<mailto:lispflowmapping-...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/lispflowmapping-dev _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
