Revert "Remove support for actions/rpc/notifications" This reverts commit beaac808943b25f5627c70ddb5029408101204a7. JIRA: CONTROLLER-2090 Change-Id: I3a624a4c5ef8159d2667794f734609f0a2be3e5b Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Remove support for actions/rpc/notifications The concepts underlying what we are doing here are gone from MD-SAL. Update the version of the XML namespace and remove support for - action-implementation - action-instance - notification-listener - rpc-implementation - rpc-service - specific-reference-list - static-reference JIRA: CONTROLLER-2090 Change-Id: I7d9c992108378283a83ce80d6612794ccac1730e Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
Remove deprecated MD-SAL APIs The APIs in controller have been deprecated for removal and cannot sustain an upgrade to Guava-28+. Remove them along with all supporting implementations. JIRA: CONTROLLER-1903 Change-Id: I213797b7045cfd7bef744e249614e2b1f6169c1c Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
BUG-7608: Add ActionServiceMetadata and ActionProviderBean This patch add the new concepts of action-provider and action-service. The implementation does nothing, as we are transitioning from a run-time logic being coupled with sal-remoterpc-connector. This allows us to migrate users, while retaining behavior indepent of sal-remoterpc-connector's actions. This will allow us to fix BUG-3128. Once it is fixed, and DOMRpcRouter can express the action-provider advertisement, we are going to actiovate the commented-out code ActionServiceMetadata.acceptableStrategy(). Change-Id: I3f412d092c10b51a198721f288fdefdfc907f0b7 Signed-off-by: Robert Varga <rovarga@cisco.com>
Configurable update-strategy for clusteredAppConfig Any change to application's config data results in restart of the blueprint container. This change adds an attribute that allows different applications to disable this restart. Attribute added: update-strategy Values: reload, none. Default: reload Change-Id: Ie0c7501f8b5c84970a46ca8f02d7f77caf913a0a Signed-off-by: Vishal Thapar <vishal.thapar@ericsson.com>
Extend clustered-app-config to read default data from XML file The default data can be specified in the clustered-app-config element but it's also useful for scripting/automation or convenience to be able to specify the default data in external XML file. The clustered-app-config will now look for a file of the form <yang module name>_<container name>.xml in a well-known location, etc/opendaylight/datastore/initial/config. The XML file name can also be explicitly specified via the "default-config-file-name" attribute. Change-Id: Id310ef5ae121b8b9444a2102b93c3e382e421687 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add "static-reference" blueprint extension Added a blueprint extension, "static-reference", that obtains an OSGi service and returns the actual instance. This differs from the standard "reference" element that returns a dynamic proxy whose underlying service instance can come and go. This is useful especially in cases where the service exists for the life of the karaf container and you don't need/want the overhead of the proxy. Change-Id: I4cbcc7e2b5a85b0a22e50e12f3946d29bfb36c7d Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add "specific-reference-list" blueprint extension Added a blueprint extension, "specific-reference-list", that obtains a specific list of service instances from the OSGi registry for a given interface. The specific list is learned by first extracting the list of expected service types by inspecting RESOLVED bundles for a resource file under META-INF/services with the same name as the given interface. The type(s) listed in the resource file must match the "type" property of the advertised service(s). In this manner, an app bundle announces the service type(s) that it will advertise so that the extension knows which services to expect up front. Once all the expected services are obtained, the container is notified that all dependencies are satisfied. This new extension will initially be used by the bgpcep project. Change-Id: I3bc6a72134b33c744fbb48fd645dd3a0ca54673d Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add clustered-app-config blueprint extension Added an extension that obtains a given binding DataObject type from the data store and provides the DataObject instance to the Blueprint container as a bean that can be injected into oher beans. In addition it registers a ClusteredDataTreeChangeListener to restart the Blueprint container when the data is changed. If no DataObject instance exists, an instance is created with any defaults values populated. Default data may be specified via the "default-config" child element which must contain the XML representation of the yang data, including namespace, wrapped in a CDATA section to prevent the blueprint container from treating it as markup. It is assumed the given "binding-class" is a top-level yang container or list, which seems reasonable. If it's nested then the full path would have to be specified via XML which is doable but not worth the added work if not necessary. We'll see if there's a use case for a nested app config (I doubt it). A list agg config would be used if there's multiple instances of the app/module (eg "openflow-switch-connection-provider-impl" in the openflowplugin). The "list-key-value" must be specified. It is assumed there's only one list key and that it's a string, ie the yang list is keyed by the name of app/module. Change-Id: Ib970b003526d42c2a3db085036174967f055cbba Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add blueprint extension to register notification listener Added a blueprint extension element <notification-listener> that registers a NotificationListener implementation with the MD-SAL NotificationService. Change-Id: I5ba9b1124ccba4d5c0f8d2e323eb3dd0e918cd94 Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add blueprint extensions to get and register RPC services Added several blueprint extension elements to support RPCs: <rpc-implementation> - registers a global RPC implementation. If "interface" isn't specified, it registers all RpcService interfaces implemented by the ref'ed instance. <routed-rpc-implementation> - registers a routed RPC implementation and returns a RoutedRpcRegistration instance for injection into other beans via the specified "id. If "interface" isn't specified, it looks for a single RpcService interface implemented by the ref'ed instance. If multiple are found it fails since only one RoutedRpcRegistration instance can be returned. <rpc-service> - finds the registered RpcService corresponding to the specified "interface" and makes it available for injection into other beans via the specified "id". Internally the bean implementations obtain the binding RpcServiceRegistry. Change-Id: I432dfb5378ca8368e41fb5375c9d5515dd3e714d Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add decorating "type" attr extension for service refs Added an attribute extension to the <service> element that adds an OSGi service property of the form "type=<value>". This allows providers of a service to advertise the type of the service to distinguish it from other services provided for the same interface. Conversely, the extension can also be used in <reference> elements to allow consumers of the service to specify which service implementation they want. As a convention, the "default" type should be used for the default implementation of the service with other types being specialized implementations. This allows consumers to obtain whichever implementation the provider deems as the default without having to explicitly know it and allows the provider to switch to a new implementation without requiring all consumers to change their referenced type. If a consumer doesn't specify the "type" attribute, it may be ambiguous as to which service is obtained. Rather than requiring that the "type" attribute be specfied for every <reference> element, I added an attribute extension attribute, "use-default-for-reference-types", to the <blueprint> element that automatically adds a filter to all <reference> elements where the "type" property is either not set or set to "default" if the "type" attribute isn't explicitly specified. This ensures the default implementation is imported if there are other implementations advertised with other types. Change-Id: Ie61bb45da1c7539732cd31ab0f8130233c9696fc Signed-off-by: Tom Pantelis <tpanteli@brocade.com>
Add restart-dependents-on-update blueprint extension Added an attribute extension to the <blueprint> element that adds a bean processor that scans for any "property-placeholder" elements and reacts to changes to the corresponding cfg file by restarting this blueprint container and any dependent containers that consume OSGi services provided by this container in an atomic and orderly manner. This mimics the module restart functionality provided by the CSS. A new OSGi service, BlueprintContainerRestartService, was added that performs the orderly restart. This service is created and registered by the BlueprintBundleTracker. Change-Id: I5f463303c3a8aba35b3ed914268bdc67ac795a5a Signed-off-by: Tom Pantelis <tpanteli@brocade.com>