I have a scenario where I have to rename one required request param. My application is already live. I want to deprecate the existing request param and want to add new request parameter. So my existing applications will be sending me the old request parameter and new application will start to send the new param.
Now I want to add validation, either I can mark both params as required or optional. But my business logic is either of param is required.
For example I already have a path parameter group and now I want to rename it to pageGroup. So either page or pageGroup is required.
How can I achieve it in Spring Boot? Any suggestions are welcome :)
Related
Here a solution is described to handle redirects to a custom URL based on a condition via use of AccessStrategy.
This however is part of the unauthorized login logical flow therefore results into a still not-logged in user arriving at the end url we redirect to. (via getUnauthorizedUrl)
If we want to redirect the user based on a condition, say via injecting an action to the webflow, how can we manipulate the return URL to be changed into a custom one?
WebUtils.getService(requestContext) include getters of the source/originalUrl but no obvious way to set/manipulate said value through an action bean.
p.s. Currently using CAS version 5.3.x
Responses for normal web applications from CAS are built using WebApplicationServiceResponseBuilder.
If you examine this block you will find that the final response is built using WebApplicationServiceResponseBuilder bean. It is only created conditionally, if an existing bean is not already found in the context by the same name. So to provide your own, you just need to register a bean with the same name using your own #Configuration class.
#Bean
public ResponseBuilder<WebApplicationService> webApplicationServiceResponseBuilder() {
return new MyOwnWebApplicationServiceResponseBuilder(...);
}
...and then proceed to design your own MyOwnWebApplicationServiceResponseBuilder, perhaps even by extending WebApplicationServiceResponseBuilder and overriding what you need where necessary to build the final redirect logic conditionally.
To learn about how #Configuration classes work in general, you can:
Review this post
or this post
or consult the documentation for Spring and/or Spring Boot.
In spring integration you can set the properties mapped-request-headers, mapped-response-headers and header-mapper in an outbound-gateway.
My target is to filter out specific headers, so I need some kind of blacklist. But the first two attributes are whitelists. I can either say mapped-request-headers="*", then every header will be passed, or I can put some specific headers, but then only these headers will be passed. But that's not what I want.
I could somehow overwrite the header mapper and add this bean to the header-mapper attribute, but is this the way of doing this? (I wonder why headers can be whitelisted but not blacklisted). Isn't there some functionality to set "filter spring added headers" and "pass manually added headers" or something?
You don't say what Spring Integration version you are using, or the type of endpoint you are using.
Since version 4.3, mappers that extend from AbstractHeaderMapper (AMQP, SOAP, XMPP) now support negated headers "!foo,!bar,baz*".
If you are not using one of these protocols, you can use a header filter upstream of the endpoint (for outbound) or right after the endpoint (inbound).
For the HTTP header mapper (DefaultHttpHeaderMapper) you can wire in a custom bean of that type where you add any standard headers you wish to exclude via the excludedOutboundStandardRequestHeaderNames and excludedInboundStandardResponseHeaderNames properties.
#RequestParam(value = "param") String param
How to validate this param in elegant way ? More exactly I must check if param is some value in database. My stack is: spring-boot+mybatis
This might be a duplicate of that one but anyway.
There's a difference in the way you validate forms and separate parameters. With POST it's actually impossible to break the request into separate parameters and you get the whole post body, and you use #Valid to process it. With GET it is possible to have separate parameters as arguments in method, and in this case Spring proprietary #Validated annotation should be used.
I have web services developed using Jersey, and a service take as parameter a Java Bean annotated with #QueryParam annotations on fields. It works fine when the service is invoked directly via its URL. Now I wish to call that service programatically from another piece of code (a JSP in the same WAR, say). I wish to have the bean parameter filled in with the query parameters of my current request, basically doing myself what Jersey does for me automatically when I call the service URL.
I want really to be able to take the request parameters and inject them into the relevant bean fields. I know I could do that myself with BeanUtils and reading the annotations myself, but surely there is an easier way?
Example code:
My service defines this method
#GET
public Response generate(#BeanParam Options options){...}
And Options is a Bean that has fields like
#QueryParam("format")
private String format="pdf";
I want to be able to write something like:
Options myoptions=new Options();
???.inject(myoptions,request);
in my JSP.
Does it make sense?
let's assume we have a signup form. When some input of the form is changed, I want to validate its value on the fly by using the ajax call to the server. Is there a chance to validate only some particular property of the bean by using the JSR 303 validation?
The signup form handler validates the received bean just fine, but I want to find out the way to check the property before submit the whole bean.
The straight forward approach is just to create a server-side method to receive the property name and value and based on the name check the value, but I hope there is a way to use already defined constraints for the bean.
For example, the user entered the email address and moved forward to the next property. The client makes a call and the server method checks if the provided email is already exist. If so, it returns an error and I do show it up on the client side. I believe it may make the signup process more flexible and user friendly
Any comments are really appreciated.
The jsr-303 Validator does have a method right on it to validate just one property:
<T> java.util.Set<ConstraintViolation<T>> validateProperty(T object,
java.lang.String propertyName,
java.lang.Class<?>... groups)
You just need to inject the validator so that you can use it directly, rather than relying on Spring to call it automatically via putting #Valid on a method parameter.