I'm new to Opendaylight and I'm currently trying to develop an app to get packet-in, analyse them and then dispatch them to other app.
Does the blueprint replace the need for creating an Activator class to register the component with the OSGi framework? Or do we still need the activator to instantiate and set the dependencies?
As far as I can tell, the blueprint already does that, am I correct?
Any help would be extremely appreciated!
Yes, Blueprint takes care of the OSGi registration and discovery for you, as long as you declare the appropriate elements in the Blueprint descriptor: <reference/> to find a service, <service/> to expose one. The Using Blueprint page on the ODL wiki covers Blueprint usage in some detail, including OSGi integration and MD-SAL integration.
In many cases, if you’re using the ODL parent POMs you can take advantage of Blueprint autowiring, using #Singleton and #Inject annotations instead of writing an XML file.
(You can ignore all the Config Sub-System sections, that’s deprecated.)
Related
I'm searching for a well documented XACML3-Framework in the open source world. I tried AuthZForce and AT&T XACML. Both seems to have many features. The problem: to get them running, I have to read the source code or find test-classes. There are no examples or anything else, that helps to understand the functionality of the framework. I thought XACML is the future of authorization but at the bottom there is no real community.
Is there an XACML-alternative for ABAC-implementations or is there no other way and I must use RBAC with programmed constraints?
Regarding AuthzForce Core (Java library), you have a tutorial on the home page of the github project: Getting started; and an example of usage with a PEP in a real-world scenario. If you are missing info on something, feel free to contact us on our support mailing list. I also emphasize the fact that all Java classes have Javadoc and Javadoc artifacts are published on Maven Central with every release. You can download them manually or make sure your IDE is properly set up to automatically download them when you use Maven dependencies in your Java project.
WSO2 IS can help (opensource):
https://docs.wso2.com/display/IS510/XACML+Architecture
http://wso2.com/library/tutorials/2016/02/tutorial-how-to-enable-role-based-access-control-for-wso2-api-manager-using-xacml/
Policy handling can be done via web interface (Carbon).
I'm developing an app with IBM MobileFirst Platform and I find an issue with Worklight.js file. Worklight.js is extending Function prototype defining several methods like bind, curry, wrap and so on.
My app is built with aurelia framework an after upgrading the framework to the last version I'm facing a funky issue related to bind extension.
If I comment the bind extension in worklight.js everything seems to work like a charm (don't know why worklight implements its bind version).
Worklight.js file seems to be added to the wlapp package at build time. Is there a way I can override this file so I do not have to modify .wlapp file each time app is built?
Thanks
The direct answer to the specific question you've asked is, no, there is no way provided to override worklight.js. This is the core JavaScript code needed for the MobileFirst Platform client-side to function, and as such the user isn't given any means to modify it - it's injected into your app (i.e., into the WLAPP file) during the build process.
I'm not aware of any specific issues with Aurelia, but have certainly seen cases in the past where an app that uses two different frameworks (e.g., MobileFirst Platform / Worklight, and something else) "fight" with each other because they both want to implement extensions that are not compatible with each other - in which case, one framework or the other usually needs to change to accommodate the other.
If you are a customer with paid support, I'd suggest opening a PMR so we can get our developers to take a look at the issue.
I have the same problem with Angular. Worklight bind makes Angular controller fail to instantiate. The solution is to recover the bind function after worklight is loaded.
var bind = Function.prototype.bind;
window.wlCommonInit = function() {
Function.prototype.bind = bind;
};
I had used DryIoc and LightInject in most of my .Net Web API 2+ solutions. Using new architecture, I would prefer to use NServiceBus or MassTransit for my next ESB implementation. However, I could not find any useful code reference that could help me to do Implementation of the NServiceBus/MassTransit IContainer with DryIoc or LightInject. Other IoC is not an option for me as the requirement from my company is to choose only from both of the above mentioned. Greatly appreciate any help from the community.
Will this help? "If you have your own container that is not already supported by a NuGet package, you can create a plugin centering around the IContainer abstraction. Once this is created and registered, NServiceBus will use your custom container to look up its own dependencies."
I have started working with Ninject for a website and setting up DI within a project.
I have noticed you register the binding dependencies within the app_start called ninjectWebCommon. When the project loads, do all dependencies get registered? For example if you have over 50 dependencies registered, will this cause resource issues? Or does each instance gets registered on page execution? If not, Is there a way to lazy bind the dependencies or is this unnecessary?
Is there a better way of accomplishing this even if using another IOC Container?
You should read about Register Resolve Release pattern. Basically registration process is quite simple, you tell the container which types to use for resolving abstractions. No objects are created in this process. DI container creates the instances when a request hits your application. They may be created only once or on every request, depending on the life cycle.
You do registrations like that for other containers as well and it really shouldent be a resource issue. However Ninject is a bit on the slow side. If you can choose as you like you might be better off with a DI container like SimpleInjector.
For a comparison i used a website with some benchmarks.
I'm using FuseESB to run my app, which is essensially OSGI container (Felix), i'd like to figure approach to test my OSGI services in integration mode (including outer dependencies like DB, outer services, etc). First on a thought is ability to run specific bundle into container which involve all app services into running tests defined in this bundle. Can somebody help with that kind of issue? THANKS!
There are differnt ways of testing this.
Since FuseESB is based on Apache Karaf you might test with the apache karaf-pax-exam tools to test a complete container setup automatically.
Another way of just testing your OSGi bundles in a OSGi container is to use pax-exam directly. Last but not least if you just want to test your service look-up functionality you might test with pojosr, it's quite nice for testing but has it's limits especially if you depend on container features.
That said you'll find information at the following pages:
Pax-Exam
Apache Karaf
sample how Pax-Web uses pax-exam in its iTests
You may find http://www.javabeat.net/2011/11/how-to-test-osgi-applications/ helpful as an overview of the various OSGi test options. Configuring PAX-Exam to pull in your whole FuseESB container and get all your app services present will involve certain challenges, but once you've got the knack it can be very handy.
bndtools as the possibility to do JUnit tests inside the container.