The #Inject annotation works fine in Helidon MP application. However, I can't find #Inject for Helidon SE. How do we achieve dependency injection in SE?
Helidon SE's philosophy is to give you full control of everything ("no magic"), so it does not intrinsically support dependency injection (this is a deliberate choice and a deliberate tradeoff). If you prefer the dependency injection style of programming, I recommend you use Helidon MP, which is, as a MicroProfile implementation, explicitly designed for it.
Related
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.)
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).
We use NLog or Serilog to do logging. We're busy porting a system from ASP.NET to ASP.NET Core, which has logging built in.
Ideally, we'd like to drop NLog, as there doesn't appear to be a need for it anymore.
However, is the built in logging equivalent to NLog? Is it missing any major features? Is there any point in continuing using NLog (or something similar e.g. Serilog)?
The ASP.NET logging is a common (logging) interface and log implementation.
You could use the common interface and 3rd party library (e.g NLog) together as the infrastructure is prepared for that.
If you take NLog over the built-in logging implementation you win:
changing configuration on-the-fly (while running application without restart)
more targets (e.g. database, file). There is no file target in the built-in: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging. The mail target in NLog isn't in .NET Standard yet, but it's planned. The mail target is there for .NET Standard 2 and for .NET Standard 1 there is NLog.MailKit
more options in targets (e.g. file archiving)
writing extra context info, like ${processid}
as we invest a lot of in performance optimization, I would expect performance.
async logging - which isn't in ASP.NET logging as far as I know.
advanced features like buffering, fallbacks & limiting your logs, filter conditions with context info, writing concurrent to one file etc.
NLog is easier to extend (not only targets but also layout renderers, layouts etc.)
possibility for structural logging (Serilog, NLog 4.5)
But as always, if you don't need these features then maybe less (libraries) is more.
I wouldn't say that ASP.NET Core's logging API makes NLog and other providers obsolete. What ASP.NET Core provides is a nice abstraction so logging frameworks can be switched without changing code that depends on logging.
Nlog still provides useful configuration features that are not implemented in ASP.NET Core logging API.
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.
Greetings, we have a project with loads of beans, JSP and etc. There is a desperate need for performing automated tests in our environment (we use Maven). Now, we can easily write tests for database project layer, for various security utilities we implemented. But the JSP pages remain untested.
I searched for utilities for server-side testing and Cactus seems the best option. However, according to their changelist, their last release is 1.8 and it was released more than two years ago!
So the question is - what happened to Cactus, is it still developing or what? And what are the recent alternates for Jakarta Cactus (if any exists)?
I've used a combination of Spring, JUnit and HttpClient with some success in recent projects.
Apache HttpClient provides a powerful and flexible API for constructing and sending http requests into your application. It cannot replicate a web browser, say by running client side scripts, however if there is sufficient content within the resulting http responses (headers, URI, body), then you can use this information to traverse pages within the application and validate the behavior. You can post forms, follow re-directs, process cookies and supply the inputs into your application.
JUnit (junit.org) drives the tests, invoking a series of pages with HttpClient and can be deployed alongside the application, run standalone with ant/maven, or run separately inside your IDE.
Spring (springsource.org) is, of course, optional as you may not be using it for your project. I've found it useful to stub/mock out parts of the application, such that I can isolate specific areas, such as front-end controllers, through to the business logic, by substituting the DAOs to return specific data values. It provides an excellent Test Context Framework and specialized TestRunners that hook in well to testing frameworks like JUnit (or TestNG if you prefer).
Cactus served as a good server-side testing framework in the ejb2 ages and but it's not supported anymore.
You can use combination of both Mock testing (fine-grained) and In-Container testing (coarse-grained) strategy to test your application completely.
Mock Testing Frameworks : Mockito, Jmockit, EasyMock etc..
Integration Testing Frameworks (Java EE) : Arquillian, Embeddable API, etc..
I prefer Mockito and Arquillian for server-side testing.
How about Arquillian? I haven't used it and it doesn't even have a stable version yet, but at least it's in active development.
You might want to try selenium. That with jBehave is a good combination I'm finding. And the more support for both those projects, the more they will not go defunct (like cactus).