Shulou(Shulou.com)06/02 Report--

This article focuses on "summing up the use of Spring BeanUtils to avoid all kinds of weird attribute copy problems", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "summarize the use of Spring BeanUtils to avoid all kinds of weird attribute copy problems"!

Background

Recently, in the project, we are jointly debugging an interface with a third party. Our side sends a http request to the other party, and then receives the response from the other party. The codes are all old codes. According to the comment, the Request class written in the other party's SDK has a bug that cannot be serialized, so a Request class is rewritten here. The basic properties are all the same, but the point is that one property is a static inner class and two are list attributes, similar to the following:

Private List orders; private AddRequest.Ticket ticket; private List payments

AddRequest is our own rewritten request class. The request class in their SDK is MixAddRequest. After assembling the request parameters, we use the copyProperties method of BeanUtils of Spring to copy the attributes in AddRequest to MixAddRequest, and then send the request. So far, everything is supposed to be perfect.

And the request failed, Nani? The other side said that the lack of a necessary field, parameter verification failed, a check field name, is a field in the Ticket this class, quickly look at the code, the heart is full of confidence in the old code, thinking that there must be something wrong, or they secretly moved the code, the field from optional to required, hehe.

Sure enough, the setting was found in the code, and now they should be sure of their problems, and then open a debug, ready to sentence them to death. It turns out that the request sent to them does not have this field. There was only one method of Spring's copy property in the middle, which was weird at the time.

Since there is only such a line of code in the middle, the mystery must be in it. It is suspected that the two static inner classes are different, so I write Demo, prepare to make a copyProperties method of this BeanUtils, write two classes and a Main,@Data and @ ToString is the annotation of the lombok plug-in, which is used to automatically generate getter and setter methods as well as toString methods.

ToString @ Data public classCopyTest1 {public String outerName; public CopyTest1.InnerClass innerClass; public List clazz; @ ToString @ Data public static classInnerClass {public String InnerName;}} @ ToString @ Data public classCopyTest2 {public String outerName; public CopyTest2.InnerClass innerClass; public List clazz; @ ToString @ Data public static classInnerClass {public String InnerName;}} CopyTest1 test1 = new CopyTest1 () Test1.outerName = ""; CopyTest1.InnerClass innerClass = new CopyTest1.InnerClass (); innerClass.InnerName = "hohoho"; test1.innerClass = innerClass; System.out.println (test1.toString ()); CopyTest2 test2 = new CopyTest2 (); BeanUtils.copyProperties (test1, test2); System.out.println (test2.toString ())

The first pit is encountered here. At first, it is easy to write the attribute as public, thinking that the getter and setter methods are omitted and the @ Data annotation is not added. As a result, after running test2, all the attributes are null, and none of them have copy past. Add @ Data to continue to run. Sure enough, the basic attribute (String) has been copied, but the inner class is still null in test2. That verifies that it is really the problem of the internal class. I can't believe my eyes. After all, the code that has been running online for so long.

When you know the problem, you always have to figure out how to solve it, so you need to set the inner class and copy separately. If the inner class has many bean attributes or recursive bean attributes, you can encapsulate a method for recursive copy. I have only one layer here, so you can directly copy it once.

CopyTest1 test1 = new CopyTest1 (); test1.outerName = ""; CopyTest1.InnerClass innerClass = new CopyTest1.InnerClass (); innerClass.InnerName = "hohoho"; test1.innerClass = innerClass; System.out.println (test1.toString ()); CopyTest2 test2 = new CopyTest2 (); test2.innerClass = new CopyTest2.InnerClass (); BeanUtils.copyProperties (test1, test2) BeanUtils.copyProperties (test1.innerClass, test2.innerClass); System.out.println (test2.toString ())

Remember that the properties of the inner class must also have a setter method, otherwise it will also cause copy to fail. You still remember that I mentioned that there are two List attributes at the beginning, why mention this? Guess what

In fact, the two classes in list are also rewritten inner classes, they are also different, but they passed smoothly copy at that time, why? Because the generics of java only work at compile time, at run time, the list property is a collection that stores Object. After copy, the orders property of MixAddRequest is actually a collection of Order classes, but it is not a collection of its own inner classes, but a collection of AddRequest's inner classes, but because the other party parses json, there is no error.

At this point, I believe you have a deeper understanding of "summing up the use of Spring BeanUtils to avoid all kinds of weird attribute copy problems". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.