In a example like:
#GetMapping(value = "/artists", params = "genre")
public List<Artist> getArtists(#RequestParam String genre) {
}
is including genre in the params redundant since it is also declared using #RequestParam in the method signature ?
When trying to map to different methods for the same URL, is the method signature the one that metters, or is also defining params necessary?
In the #RequestMapping annotation (and other HTTP method specific variants), the params element is meant for narrowing the request mappings based on query parameter conditions. From the documentation:
The parameters of the mapped request, narrowing the primary mapping.
Same format for any environment: a sequence of myParam=myValue style expressions, with a request only mapped if each such parameter is found to have the given value. Expressions can be negated by using the != operator, as in myParam!=myValue. myParam style expressions are also supported, with such parameters having to be present in the request (allowed to have any value). Finally, !myParam style expressions indicate that the specified parameter is not supposed to be present in the request.
In the other hand, the #RequestParam annotation allows you to bind a query parameter to a method argument.
Refer to the documentation for details.
Related
As you can see in the title , I'd appreciate it if somebody can tell the usage of the Class .
There's a inside enum Type ,how to use it?
public static enum Type {
BETWEEN(2, "IsBetween", "Between"), IS_NOT_NULL(0, "IsNotNull", "NotNull"), IS_NULL(0, "IsNull", "Null"), LESS_THAN(
"IsLessThan", "LessThan"), LESS_THAN_EQUAL("IsLessThanEqual", "LessThanEqual"), GREATER_THAN("IsGreaterThan",
"GreaterThan"), GREATER_THAN_EQUAL("IsGreaterThanEqual", "GreaterThanEqual"), BEFORE("IsBefore", "Before"), AFTER(
"IsAfter", "After"), NOT_LIKE("IsNotLike", "NotLike"), LIKE("IsLike", "Like"), STARTING_WITH("IsStartingWith",
"StartingWith", "StartsWith"), ENDING_WITH("IsEndingWith", "EndingWith", "EndsWith"), NOT_CONTAINING(
"IsNotContaining", "NotContaining", "NotContains"), CONTAINING("IsContaining", "Containing", "Contains"), NOT_IN(
"IsNotIn", "NotIn"), IN("IsIn", "In"), NEAR("IsNear", "Near"), WITHIN("IsWithin", "Within"), REGEX(
"MatchesRegex", "Matches", "Regex"), EXISTS(0, "Exists"), TRUE(0, "IsTrue", "True"), FALSE(0, "IsFalse",
"False"), NEGATING_SIMPLE_PROPERTY("IsNot", "Not"), SIMPLE_PROPERTY("Is", "Equals");
// Need to list them again explicitly as the order is important
// (esp. for IS_NULL, IS_NOT_NULL)
private static final List<Part.Type> ALL = Arrays.asList(IS_NOT_NULL, IS_NULL, BETWEEN, LESS_THAN, LESS_THAN_EQUAL,
GREATER_THAN, GREATER_THAN_EQUAL, BEFORE, AFTER, NOT_LIKE, LIKE, STARTING_WITH, ENDING_WITH, NOT_CONTAINING,
CONTAINING, NOT_IN, IN, NEAR, WITHIN, REGEX, EXISTS, TRUE, FALSE, NEGATING_SIMPLE_PROPERTY, SIMPLE_PROPERTY);
...}
Part is internal to Spring Data. It is not intended to be used by client code. So if you don't implement your own Spring Data Modul you shouldn't use it at all nor anything inside it.
A Part is basically an element of an AST that will probably result in an element of a where clause or equivalent depending on the store in use.
E.g. if you have a method findByNameAndDobBetween(String, Date, Date) parsing the method name will result in two parts. One for the name condition and one for the DOB between condition.
The type enum lists all the different types of conditions that are possible.
The parameters of the elements are the number of method arguments required and (possibly multiple) Strings that identify this type inside a method name.
I have Spring 3.2 web app and i have controller with following request mappings:
#RequestMapping(value = "/test/{param1}", method = RequestMethod.GET)
public String method1(#PathVariable(value = "param1") String param1, ..
#RequestMapping(value = "/test/login", method = RequestMethod.GET)
public String method2(//..
Can I be sure that if someone ask for url /test/login the method2 will be invoked? Are there any factors based on which spring decides how to handle it? Does it always choose URL without PathVariable if any exists? I can't find anything in Spring doc.
Can i be sure that if someone ask for url /test/login the method2 will be invoked?
Yes.
The mappings are resolved by specificity, the relevant piece of doc is available here
A pattern with a lower count of URI variables and wild cards is
considered more specific. For example /hotels/{hotel}/* has 1 URI
variable and 1 wild card and is considered more specific than
/hotels/{hotel}/** which as 1 URI variable and 2 wild cards.
If two patterns have the same count, the one that is longer is
considered more specific. For example /foo/bar* is longer and
considered more specific than /foo/*.
When two patterns have the same count and length, the pattern with
fewer wild cards is considered more specific. For example
/hotels/{hotel} is more specific than /hotels/*.
If the two mappings match a request, a more specific will apply. Out of the two mappings, /test/login is more specific.
I'm afraid it is not the expected answer, but as it is not specified in the documentation it should be regarded as undefined.
You could just try (eventually with putting "/test/logging" method first if source file), but even if it worked, you could not be sure that it will still work with another version of Spring Framework.
My advice is: if you can, avoid such ambiguous URLs, if you cannot, just have a single catchall #RequestMapping and forward from it by hand:
#RequestMapping(value = "/test/{param1}", method = RequestMethod.GET)
public String method0(#PathVariable(value = "param1") String param1, ...
) { // union of all parameters for both method1 and method2
String ret;
if ("login".equals(param1)) {
ret = method2(/* pass parameters for method 2 */ ...);
}
else {
ret = method1(/* params for method1 */ param1, ...);
}
return ret;
}
public String method1(String param1, ..
public String method2(//..
That way, you have full control on what method processes what url. Not necessarily the nicest way, but it is at least robust ...
I've defined a class for CRUD operations on comments. The read method is overloaded.
class Comment{
// method 1: returns all the comments by a user
findAll(long userId, long subjectId, String param);
// method 2: returns all the comments of all the users
findAll(long subjectId, String param)
}
The point cut expression I've tried is
#Around("execution(* com.package..*Controller.findAll(..)) && args(userId,subjectId,..)")
public Object validateFindAll(final ProceedingJoinPoint proceedingJoinPoint, final long userId, final long subjectId) {
// validate userId, if available
// validate subjectId
}
Problem: As the data types for userId and subjectId are same, the point expression when applied to method 2 shifts the param values by 1 place. This means, the expression does not understand that the first parameter userId isn't passed. Instead, userId gets 'subjectId' as value and the subjectId gets the adjacent parameter 'param' as its value.
Note
I am trying to avoid writing another method like findUserComments().
I want to maintain consistency across the application. There are other classes with similar patterns of CRUD operations.
Question: Is it possible to define an expression applicable to both the methods with the first parameter userId being optional ?
EDIT - Solution
While I was playing around with different approaches as suggested in the solutions below, I've finally removed method 2. I handle that case in method 1.
You cannot explicitly bind an AspectJ parameter and then expect it to match an incompatible signature. Thus, your pointcut will only match findAll(long, long, ..), i.e. "method 1" in your example. You can specify optional arguments with .., but then you cannot bind them to named parameters.
For example, it is possible to match both methods and bind long subjectId and String param via args(.., subjectId, param) because both parameters are predictably right-aligned at the end of the signature. If you want any optional (and thus unbound) parameter, you need to use thisJoinPoint.getArgs():
#Around("execution(* com.package..*Controller.findAll(..)) && args(.., subjectId, param)")
public Object validateFindAll(
final ProceedingJoinPoint thisJoinPoint,
final long subjectId,
final String param
) {
if (thisJoinPoint.getArgs().length == 3)
System.out.println(thisJoinPoint + " -> " + thisJoinPoint.getArgs()[0] + ", " + subjectId + ", " + param);
else
System.out.println(thisJoinPoint + " -> " + subjectId + ", " + param);
// (...)
}
But while getArgs() is dynamic, it probably is slower than parameter binding because it uses reflection. Maybe having two pointcuts is not so bad after all. If your advice method does complicated things before/after proceed(), you can still factor those things out into helper methods and call them from both advice.
Problem is related to method averloading actually. Since, you are passing long userId and long subjectId AOP will always try to match those arguments. Solutions could be
1) Create another pointcut for other argument i.e. 1 for long,long and other for long, String
2) Use variable argument signature in the begining such as
#Around("execution(* com.org..findAll(..)) && args(..,subjectId,param)")
public Object validateFindAll(final ProceedingJoinPoint joinPoint, final long userId, final long subjectId) {
}
instead of using variable argument in the begining. Then you can use getArgs() method to figure out arguments.
This is simple solution but may slowdown your processing.
3) Though as a design issue, I would suggest to encapsulate all your parameters in one single object and pass it. Instead of passing multiple parameters. It will help you in future as well.
I'm building an web application using Spring 3.0 MVC.
I have a method which has prototype below.
#RequestMapping(value = "/blahblah/blah.do", method=RequestMethod.GET)
public void searchData(#RequestParam(value="uniqOid", required=false) String uniqOid, #ModelAttribute("MasterVo") MasterVo searchVo,
ModelMap model, HttpServletResponse response, HttpServletRequest request)
The problem is that, the view (jsp) contains inputs that matches to searchVo(ModelAttribute).
When the int or long value of searchVo didn't come from the jsp, the server throws 404 page not found exception.
If the type of value is "String", it has no problem.
In my opinion, it is the problem of type casting.
How could I solve this problem, and which part of the server code that I have to check?
Thanks in advance.
I will go ahead and assume a few things about your problem.
It is not a type-cast problem. Spring has default converters that can easily convert from a String to some primitive type.
Now what you are facing is I think a null assigment to primitive type problem. Suppose the name of the property that's causing the problem is named primitiveProperty. Now, the request-paramters could include a parameter named primitiveProperty with an empty-String value, or some value that cannot be converted to a number. If the type of the primitiveProperty is String, it can assign the value of that parameter to it without any problem.
If the type of the primitiveProperty is int, long or some other primitive type that cannot have a null value, a problem occurs. When Spring converts the empty-string or a non-numeric string valued request-param named primitiveProperty, it cannot do so since that string can't be converted to a valid int or long value. So it is converted to null. Now, when Spring tries to assign that null value to a property that cannot have a null value (any primitve type), you get an Exception. If you are getting an empty-string as your request-param, you can replace the troublesome property in your domain object with its equivalent wrapper class (int with Integer, long with Long and so on). If you are getting a non-numeric value from your view, well, make sure that you don't get a non-numeric value.
You need to check the setter of the fields that are giving the typecast problem, in your case MasterVo .
The Spring will call the setter of the property to bind the value, where i presume you will see the error coming.
Just add a debug point to this setter and you will see the problem.
Grails has a bug with regards to databinding in that it throws a cast exception when you're dealing with bad numerical input. JIRA: http://jira.grails.org/browse/GRAILS-6766
To fix this I've written the following code to manually handle the numerical input on the POGO class Foo located in src/groovy
void setPrice(String priceStr)
{
this.priceString = priceStr
// Remove $ and ,
priceStr = priceStr.trim().replaceAll(java.util.regex.Matcher.quoteReplacement('$'),'').replaceAll(',','')
if (!priceStr.isDouble()) {
errors.reject(
'trade.price.invalidformat',
[priceString] as Object[],
'Price:[{0}] is an invalid price.')
errors.rejectValue(
'price',
'trade.price.invalidformat')
} else {
this.price = priceStr.toDouble();
}
}
The following throws a null reference exception on the errors.reject() line.
foo.price = "asdf" // throws null reference on errors.reject()
foo.validate()
However, I can say:
foo.validate()
foo.price = "asdf" // no Null exception
foo.hasErrors() // false
foo.validate()
foo.hasErrors() // true
Where does errors come from when validate() is called?
Is there a way to add the errors property without calling validate() first?
I can't exactly tell you why, but you need to call getErrors() explicitly instead of accessing it as errors like a property. For some reason, Groovy isn't calling the method for it. So change the reject lines in setPrice() to
getErrors().reject(
'trade.price.invalidformat',
[priceString] as Object[],
'Price:[{0}] is an invalid price.')
getErrors().rejectValue(
'price',
'trade.price.invalidformat')
That is the easiest way to make sure the Errors object exists in your method. You can check out the code that adds the validation related methods to your domain class.
The AST transformation handling #Validateable augments the class with, among other things
a field named errors
public methods getErrors, setErrors, clearErrors and hasErrors
The getErrors method lazily sets the errors field if it hasn't yet been set. So it looks like what's happening is that accesses to errors within the same class are treated as field accesses rather than Java Bean property accesses, and bypassing the lazy initialization.
So the fix appears to be to use getErrors() instead of just errors.
The errors are add to your validateable classes (domain classes and classes that have the annotation #Validateable) dinamically.
Allowing the developer to set a String instead of a number doesn't seem a good way to go. Also, your validation will work only for that particular class.
I think that a better approach is to register a custom property editor for numbers. Here's a example with dates, that enable the transform of String (comming from the form) to Date with a format like dd/MM/yyyy. The idea is the same, as you will enforce that your number is parseable (eg. Integer.parseInt() will throw exception).
In your domain class, use the numeric type instead of String, so by code developers will not be allowed to store not number values.