背景

因?yàn)轫?xiàng)目接口需要進(jìn)行解密,需要對(duì)數(shù)據(jù)進(jìn)行統(tǒng)一處理,就使用了ReuqestBodyAdvice進(jìn)行數(shù)據(jù)解密處理,但是偶然的發(fā)現(xiàn)supports方法會(huì)出現(xiàn)執(zhí)行兩次的情況,覺(jué)得有點(diǎn)奇異就進(jìn)行了一次斷點(diǎn)調(diào)試,然后就發(fā)現(xiàn)了執(zhí)行兩次的原因;

過(guò)程

1.默認(rèn)supports方法返回false,表示不做任何處理:

2.默認(rèn)supports方法返回true,表示對(duì)數(shù)據(jù)進(jìn)行處理:

如圖所示無(wú)論supports方法返回true還是false,只要這個(gè)ReuqestAdvice存在并且在spring中生效,supports方法都會(huì)執(zhí)行兩次;

了解了前置情況接下來(lái)就是用斷點(diǎn)進(jìn)行接口調(diào)試了:
第一次跳過(guò)supports方法后的跳轉(zhuǎn):

第二次執(zhí)行完supports方法之后的跳轉(zhuǎn):

如圖所示,如果有經(jīng)常對(duì)看源碼或者眼尖的朋友應(yīng)該就會(huì)方法兩次執(zhí)行完supports方法之后跳轉(zhuǎn)的方法名是有區(qū)別的:
第一次執(zhí)行后跳轉(zhuǎn): beforeBodyRead
第二次執(zhí)行后跳轉(zhuǎn): afterBodyRead

結(jié)論

如上述的調(diào)測(cè)結(jié)果所示,實(shí)現(xiàn)RequestBodyAdvice接口之后的攔截在成功執(zhí)行的時(shí)候會(huì)調(diào)用兩次supports方法.
而執(zhí)行兩次的原因是因?yàn)樾枰謩e對(duì)beforeBodyRead和afterBodyRead進(jìn)行判斷:
當(dāng)?shù)谝淮蝧upports方法返回結(jié)果是true的時(shí)候表示會(huì)執(zhí)行beforeBodyRead方法
當(dāng)?shù)诙蝧upports方法返回true的時(shí)候表示會(huì)執(zhí)行afterBodyRead方法.
反之亦然
PS: 一個(gè)比較容易被人忽視但是找不到解決方法的小細(xì)節(jié):
若是Controller類(lèi)上的方法參數(shù)沒(méi)有加上@RequestBody標(biāo)簽則該RequestBodyAdvice是不會(huì)被執(zhí)行的.
如果上述內(nèi)容存在問(wèn)題,麻煩各位留言指出會(huì)第一時(shí)間修改.

到此這篇關(guān)于Spring的RequestBodyAdvice攔截淺析的文章就介紹到這了,更多相關(guān)Spring RequestBodyAdvice攔截內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論