I have a bunch of RESTful web services(80) with #GET and #PUT methods. I want to add an #OPTIONS method to each service. Instead of manualy writing #OPTIONS method for each service I want to be able to inject them in the services. What is the best way to do this?
I don't know exaclty your environment, but i think the best way in technologies I use is to specify the "auto-scan" property in the configuration file, the declaration of this property differs a little from a technology to another one, but the idea remain the same : all componants are scanned at the beginning of deploiment
sorry for my english :) but i hope this response helps you
Related
I am new to Java so apologies if this is a simple thing. I have built decorators in Python for authorizing RESTFul endpoints in Flask and have just built my first Java Webserver but am unable to figure out how to create a similar decorator in Java.
I want to do some pre-checks before running the method (i.e. is the user allowed to access this route). Ideally this would be a decorator like #authorize that, if authorized, will execute the method, but if unauthorized then it would through a 403 error instead.
#Path("/")
public final class HelloWorld {
#GET
#Path("/hello")
#authorize // How would I implement this?
public String sayHelloWorld() {
return "Hello World!";
}
}
EDIT: I am using Grizzly as the web Framework and I will be using an external Policy Management System (Apache Ranger) for managing authorization.
First of all: defining such custom annotations is exactly how you can approach such things in Java. The JAX-RS specification provides all the things you need for such kind of method binding.
The thing that is slightly more complicated: how to nicely do that for the framework that you are using.
With JAX-RS and Jersey for example, creating your own annotations is well documented. And Jersey might be a good starting point, as that is simply a straight forward way to get JAX-RS working.
So, first you start by learning how to use Jersey in general, for example from vogella. Next: you can start to add your custom annotations, see here for an example.
There is even an existing question about using custom annotations for access validation.
We're trying to do a POC showing we can call an external REST service using JBPM in business-central.
We've created a new BPM, then added a REST service task. We notice at this point that a WID file is created that has REST definition. Inside the WID file, it defines things like URL, Method, and authentication.
We've sifted through all the 7.2 docs, but for the life of us, we cannot figure out how to actually set those parameters and do something useful. Does anyone have a simple "Hello World" using business central 7.2 calling out to an external process?
We see there's a predefinied REST handler: https://github.com/kiegroup/jbpm/blob/master/jbpm-workitems/jbpm-workitems-rest/src/main/java/org/jbpm/process/workitem/rest/RESTWorkItemHandler.java
We're lacking how to assemble all of this; we can't find documentation or examples on something that seems so simple.
Thank you!
If you're using Busines Central, you can edit the process model and check the data assignments for the specific REST node. In there you can set the values of the variables or use some process variable to map dynamic values. Hope it helps.
First, Please forgive me for my clumsy English.
[What I want to do]
I want to know #WebServlet annotation by Servlet 3.0 and #Path annotation by Jersey 2.22.2, It is able to using same time?
[That I want is to help]
Can I use two annotations at the same time?
If I can use those annotations, is that way how to use?
Thank you.
#Path annotation defines a path to a RESTful Web service so when you have #Path("/SomeService") it will translate into www.yourapp.com/baseRestUrl/SomeService. You can also define it on the methods which provides REST services. Note that baseRestUrl is defined inside web.xml or in class which extends Application class.
On the other hand #WebServlet("/SomePath") states that Servlet will be listening for request on the www.yourapp.com/SomePath, it is basically replacement of servlet-mapping element in web.xml. You can still configure servlets like this, it's up to you whether you prefer XML or annotation configuration.
I am using jersey for REST service. I am deploying the REST service using apache tomcat. How do i set the session key in every response.
I have tried the below piece of code
return Response.ok(response.toString(), MediaType.APPLICATION_JSON).cookie(new NewCookie("JSESSIONID", request.getSession().getId())).build();
where request is instance of HttpServletRequest. I want to is there any configuration in web.xml so that the JSESSIONID is set for every response
Generally speaking (this holds true for many frameworks!) anything you want to be used in multiple places is best done with a filter. I'm not going to show you exactly how you do it, as it is very simple and it is better for you to read the docs, but have a look here:
https://jersey.java.net/documentation/latest/filters-and-interceptors.html
You can apply these to both methods and classes, so you only need to place annotations in a couple of places.
A very useful thing for writing clean code!
I am in a situation where I have a nascent rest api architecture where each method has tons of ceremony (validation, db connection acquisition/release, authentication), raw request/response objects as the parameters, and hard-coded json strings as the output. I want to use spring mvc to help with at least some of these issues (auth & db stuff i'll need to hold off on). This would render a lot of the current architecture unnecessary. This is pretty easy except for one feature of the current architecture: dynamically adding api calls.
The entry point (servlet) for the architecture reads from an xml file that contains the path for a request and a corresponding class to load. The class must implement an interface that contains an 'execute' method which has the logic for the request. The servlet calls this execute method after loading the class. This allows dynamic extension of the api as follows. The app is packaged as a jar together with the associated config (xml) files and given to a client. The client includes this jar in his project, creates a class that implements the aforementioned interface, and adds a mapping from request url to that class in the included xml file. He then runs the app and gets access to both the original api and his custom api.
Example:
Client is given app.war, interface.jar and custom-mappings.xml. app.war contains the implementation of the core api (rest webservice), and interface.jar exposes the interface BaseController that has the method 'execute' (app.jar also uses this interface in its controller). Client then defines his own class as follows.
package custapi.controllers;
public class ExtendedController implements BaseController {
public void execute(HttpServletRequest request, HttpServletResponse response) {
// LOGIC
}
}
He compiles this class and adds it to app.war. Next, he updates custom-mappings.xml with the following entry.
/custcall/mycall
custapi.controllers.ExtendedController
He then deploys the app. The controller provided with the core api receives the request /custcall/mycall, looks it up in custom-mappings.xml, finds the class is custapi.controllers.ExtendedController, loads that class, and finally runs its 'execute' method. This allows the logic defined by the client to be run.
Ideal:
Current architecture is replaced with spring-mvc. That is, there is no more 'super' controller that parses requests and delegates to the appropriate class and, finally, method. Spring handles this. For the app that uses this new architecture, the client would receive the app.war and the spring mvc deps that expose controller annotations. The client would then create a new spring mvc controller (taking advantage of validation, parameter -> pojo mapping, object -> json conversion), compile it, and add the resulting class file to app.war. His controller would then become an extension to the core api exposed by the app. When the app is deployed, he would be able to make a request /custcall/mycall like before and have it execute the logic he defined. This ideal scenario allows clean code for the core api (which I and others programmed) and an extended api. (A downside to this approach is that the client is tied to spring. In an even more ideal scenario, the client would use framework-agnostic annotations which are mapped to spring annotations by the app. I'm not sure how easy this would be.)
I'm not sure how the above would be realized with a spring-aware controller without sacrificing the benefits of spring. I don't believe the client could simply define another spring-aware controller (correct me if I'm wrong on this). The only solution I can think of is to have a spring-aware controller that has a wildcard path (e.g., /cust_rest/*) which acts exactly the same as the current controller. The client would not get any advantages that spring has to offer, but the core api would be a lot cleaner. I was hoping there was a better solution, however. Ideally the client would get the benefits of spring without having access to the core api source code. Any ideas on this, or is my solution the best that can be hoped for?
Thanks.
(NOTE: For both scenarios, I am only guessing how the client actually gains access to the dependencies/interfaces and deploys. I have only had access to the core api project for one day, and so my understanding of it is not complete.)
Related: Runtime loading of Controllers for Spring MVC and dynamically mapping requests/URLs
The above question looks pretty similar to mine. Replies are sparse (second one is just off topic, I believe).
Provided you setup classpath scanning properly there's no need for interface. Your clients can just annotate classes with #Controller #RequestMapping("/foo/bar"). Even if this class is located in its own jar it will still be scanned. If this is a REST service consider using #RestController instead to avoid having to place #ResponseBody on each handler method.
Use spring security to do declarative authentication & authorization (what you're doing now is programmatic security)