I am looking for a way to get information about the request in the intercept method of Around Advice or somehow pass information from a HttpServerFilter to my Around Advice.
The reason for this is I am trying to implement middleware that can capture information about the controller and method handler (registerd routes for example) for a particular endpoint while also capturing information about the underlying request (headers for example).
I want to do this without having to have the method implementor add a RequestAttribute or similar to their method call, ie have to change their implementation to support the middleware.
Ideally they just add the around advice and along with the HttpServerFilter that will be registered like so #Filter("/**") work seamlessly in the backed to capture the required data.
Trying to figure the best design for my api where all calls will take in a base form of a request. The response will be very similar for all the calls.
Some requests will inherit some properties while others will not. All the calls will funnel through the same service so the base request will be what the main service takes in.
I.e.
public Response mainServiceHandler(BaseRequest request)
My question is what are people's thoughts on an empty abstract BaseRequest vs an empty interface BaseRequest? Any advantages of one over other in terms of an api? I thought an interface would always be the best manner since it is more flexible in design but wasn't sure if it applies in this case. Not too familiar with Marker interfaces but the little I read it didn't seem to be the best solution for this or does any implementation really makes much if a difference here.
Hello first things first: Im using play framework 2.2.3 for java.
Basic tutorial about authentication in play shows how to use Annotation Security.Authenticated. The problem is that whole my application (besides login and registry forms) needs to be secured.
Now I thought of overloading GlobalSettings onRequest method and include my authentication inside, so every single call of an action would perform authentication check.
But I was told its not elegant way and was told to create another annotation similar to Security.Authenticated, but working on a whole class instead of method, and put it into my custom abstract controller class, so all my controllers that extends it will inherit this annotation.
Now I'm wondering how to make this annotation. Any tips ? Where should I start ? I know basics, how to code annotation itself, but i dont know where is right place to get annotations of controllers class to check if it contains my custom annotation, and perform authentication if so.
If you're looking for an authorization + authentication plugin for Play that can secure the whole class, and hence all the action methods within it, try SecureSocial. It has its own set of annotations, and securing every action method in a class is as easy as doing:
#SecureSocial.SecuredAction
public class MyController extends Controller {
Yes it's a little bit more work than intercepting the request and doing your check there, but its a more flexible method in case you'd like to "unsecure" some of the actions later on.
Suppose I have a set of JAX-RS locators and sublocators, like the following:
#Path("/users")
public class UserListResource {
#Path("/{id}")
public UserResource getCustomer(#PathParam("id") int id) {
// Find and return user object
}
}
public class UserResource {
#GET
public String get() {...}
}
For example, a UserResource object with the ID 5 would have the path "/users/5". In my system, I have several different resources.
Now the question is: How can the server figure out the path of a given resource? Can I do this programmatically via some JAX-RS API or do I have to implement code that uses reflection? (I know how to do the latter, but would prefer the other approach.)
At the point when I need to know the path, I do not have a request object at all. For example, I have a timer which does some background processing, then changes some entities in the domain model, then informs all clients about the changed entities (including their paths).
I know that within the scope of a request, I can inject a UriInfo object that provides this, but I need to know the path in advance (to inform clients of a change that did not necessarily happen through the JAX-RS resource).
I don't want to repeat the path information in another place, and I also don't want to have a set of path fragment constants for each resource type (in this case "/users" and "/{id}").
As I read your question, you need to build a URI knowing only the resource class and the id parameter.
It can be done using the UriBuilder class as in:
UriBuilder builder=UriBuilder.fromResource(UserListResource.class);
URI uri=builder.path(UserListResource.class,"getCustomer").build(5);
It uses reflection under the hood, so it is not so easy to refactor, but it is all it is available at the moment.
Overall, be aware that something sounds rather strange with the architecture of your application. It's hard to put a finger on, but the pattern of questions you are asking is raising a number of red flags about how you're going about this. Be aware that if you are seeking to create a RESTful API to your application that you may need to stop, take a few steps back, and rethink what you are trying to do.
To your explicit questions…
Now the question is: How can the server figure out the path of a given resource? Can I do this programmatically via some JAX-RS API or do I have to implement code that uses reflection? (I know how to do the latter, but would prefer the other approach.)
The server knows the path, as that's always supplied by the user and is used to navigate through the collection of resource classes that make up your application. If you need a UriInfo instance for a particular call, you should inject it as part of that specific call:
#GET
public String get(#Context UriInfo info) {...}
Any information required from the outer context (e.g., what the resource's ID is) is best passed in during construction. You can reparse it out of the URL (obtainable from the UriInfo) again, but that's probably the wrong approach.
Otherwise, if you're doing something much more complex then you need to be more specific in your question.
At the point when I need to know the path, I do not have a request object at all. For example, I have a timer which does some background processing, then changes some entities in the domain model, then informs all clients about the changed entities (including their paths).
I know that within the scope of a request, I can inject a UriInfo object that provides this, but I need to know the path in advance (to inform clients of a change that did not necessarily happen through the JAX-RS resource).
How are you going to have the clients be informed? There's normally no mechanism to push messages from the server to the clients, and clients are typically firewalled so that they can't directly host a service.
Theoretically, you could associate (explicitly, by URL) each resource with its own RSS feed to which a client could listen to if they chose. You wouldn't be able to force clients to listen, but you could give them the option to do so. If you go this route, you don't need to know the UriInfo “ahead of time” as the location information will be present at key times (i.e., at resource creation) and afterwards you're just referring to something that you have control over.
But that's just one way to do it and it adds a lot of complexity; you'd only do it if it was critical to your application. It's often simpler to just have clients poll from time to time. (Note that some sorts of modifications are inherently very destructive; particularly altering the ID or deleting the resource. Don't expect things to cope smoothly with those.)
I don't want to repeat the path information in another place, and I also don't want to have a set of path fragment constants for each resource type (in this case "/users" and "/{id}").
Tough. Repeating information in multiple places, provided you draw it consistently from a single source, is a common practice. There's nothing actually wrong with it.
As I understand your question, you want to know the path as the request is coming in but before it hits your resource; are you open to using Servlet Filters?
JAX-RS specific filters are only supported in 2.0
For the record: after I had posted the question, I thought about our architecture a bit more and came to the conclusion that sending URLS is not as useful as I thought. The application has to know some details about the application structure anyway:
Continuing the example above: even if the client did not know the URL pattern for individual users, it must assume that there is a list of users and know its URL; it also has hard-coded knowledge what dialog to display for editing a user etc.
So all in all, attempting to tell the client (most) URLs it needs is not worth the effort. Instead, we decided to go with a custom API definition file which includes data about the resource contents and their URL scheme. This file is used to generate the following:
the server-side resource classes with the correct JAX-RS annotations
a URL scheme specification document for other developers to code against
classes for our own client (including the URL know how, e.g. user with ID 5 has the URL ...), so we don't have to worry about inconsistencies between our client and server.
This approach has the following advantages:
The need for the server to figure out the URLs from the annotations vanishes, as the client can now do that on its own once it receives a notification that includes the object ID.
We don't have to worry about inconsistencies between our client and the server, as all information is drawn from a single source.
We have one source for the API definition under version control which can be used to verify backwards compatibility with older releases.
Note:
I would probably not claim that the resulting API stays "faithful" to the idea of RESTful webservices, but it works for us and the elements that it borrows from "actual" REST architectural style should make the API clearer and easier to learn than a traditional contract-first webservice.
I'm trying to write my first client using Spring-WS and am getting a little confused at some basics. I need to insert a SAML token into the header, and I've noticed that the WebServiceTemplate class allows for both Interceptors and WebServiceMessageCallbacks.
Can someone please help me understand why I should use one versus another?
Secondly, I noticed that the WST class allows for a list of interceptors, but only a single callback. Does anyone know what the logic was behind that design decision? Why is there no ability to pass an array or list of Callbacks?
Thanks,
Eric
I was wondering the same after reading your question (-:
On this link there's a brief explanation and that's exactly how I use both. For instance, for a specific request I need to set the SOAP action:
JAXBElement<Response> response = (JAXBElement<Response>) webserviceTemplate.marshalSendAndReceive(
request,
new SoapActionCallback("PutOrganisationUnitRequest")
);
This is indeed a simple, anonymous class as mentioned in the link. An interceptor on the other hand is defined and used for all requests. Take a look at XwsSecurityInterceptor for instance, I use that to set the authentication on ALL requests.