CN117076328A - Associated service data verification method and device based on ASM byte code technology - Google Patents
Associated service data verification method and device based on ASM byte code technology Download PDFInfo
- Publication number
- CN117076328A CN117076328A CN202311132025.2A CN202311132025A CN117076328A CN 117076328 A CN117076328 A CN 117076328A CN 202311132025 A CN202311132025 A CN 202311132025A CN 117076328 A CN117076328 A CN 117076328A
- Authority
- CN
- China
- Prior art keywords
- class
- verification
- dynamic
- attribute
- check
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 98
- 238000005516 engineering process Methods 0.000 title claims abstract description 27
- 238000013524 data verification Methods 0.000 title claims abstract description 17
- 238000012795 verification Methods 0.000 claims abstract description 151
- 230000003068 static effect Effects 0.000 claims description 46
- 238000010276 construction Methods 0.000 claims description 14
- 238000007689 inspection Methods 0.000 claims description 10
- 230000008901 benefit Effects 0.000 abstract description 3
- 230000008569 process Effects 0.000 abstract description 2
- 235000010627 Phaseolus vulgaris Nutrition 0.000 description 4
- 244000046052 Phaseolus vulgaris Species 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
- G06F8/315—Object-oriented languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application discloses a related service data verification method based on ASM byte code technology, which comprises the steps of multiplexing an open source hibernate annotation type verifier through a built-in handle by the ASM byte code technology, reconstructing a judgment process of annotation type condition verification through byte codes, and generating different dynamic verification type entries for each parameter data type and nested and aggregate attributes thereof; and (3) according to the actual value of the associated attribute, different target check links are walked according to the generated byte codes of the ASM by using the same type of different parameter examples. The verification of the service data association element during operation is solved. The method has the advantages that the method is dynamically generated during use, can be repeatedly used after generation, and has high calling efficiency.
Description
Technical Field
The application relates to the field of financial business data, in particular to a related business data verification method and device based on an ASM byte code technology.
Background
In the field of financial data, the validity check of business data is more required. Typically, each phase of the traffic data lifecycle will need to be checked. In the Java open source technical stack, a data verification plug-in based on an annotation mode is mature, hibernate validator provides a simple but rich single-element verifier function, and supports custom development of the single-element verifier.
However, the current Java verifier mode cannot provide the data verification requirements of the related elements in the financial business. In a financial scenario, verification of field relevance is quite common. The bond product data needs to verify the legitimacy of different factors such as the ticket face interest rate and the reference interest rate of the bond according to the values (the reliefs, the fixed information and the floating information) of different information modes.
The hibernate checker provided by the native Java technology stack loads the check rule class corresponding to the independent annotation of each element according to the annotation information of each element of the check object through the SPI plug-in technology, interface definition and reflection technology of Java, and cannot dynamically call the check rule class of the element according to the value of the associated element.
The annotation type custom verifier disclosed in CN113821829A is a new verification rule for a single element by using a Java native annotation verifier interface and reflection injection implementation, and does not provide a mode of verifying the associated element.
The verifier disclosed in CN113126999a is an annotated verifier different from the Java technology stack, requiring that the verifier be declared in the configuration file in advance. The configuration of the verifier and the object code to be verified are separated, and convenience and maintainability for developers are reduced.
The verifier disclosed in CN113986247a is based on the c# language, and the logical relationship between the ticket element and the verifier must be preset based on the historical service data and the verification rule, which also does not have the advantage of calling the related element verifier according to the actual value of the related element when the verification object runs.
The checker disclosed in CN111444224a is also a target check link corresponding to the service data to be checked dynamically according to the service type rather than the service data value. The target check link does not change with the actual value of the service data.
The above is where the present application needs to be improved.
Disclosure of Invention
The technical problem to be solved by the application is to provide the related service data verification method and the related service data verification device based on the ASM byte code technology, wherein the ASM byte code verification class is dynamically generated during use, can be repeatedly used after generation, and has high calling efficiency.
In one aspect, the present application provides a related service data verification method based on ASM bytecode technology, including:
step S1: receiving a verification parameter object of an external request, and acquiring a Java class of the parameter;
step S2: generating a corresponding dynamic check unique class name of the Java class according to the packet name and class name of the Java class and according to the KEY.FACTORY of the Java class;
step S3: judging whether the static global handle of the dynamic verification class exists or not;
step S31: the method comprises the steps that a dynamic calibrator class is built by an ASM technology according to the configuration of a calibration assembly parent class through a built-in dynamic calibration construction class;
step S32: the dynamic verification class is generated, a static single instance handle of the class is used, a verification method of the dynamic verification class is called, after the ASM dynamic code is completed to carry out logic judgment of an associated field, a HibernateValidator native verifier class is finally called, and verification methods corresponding to other notes on the field are verified; after the inspection is completed, the error code and the error prompt information are packaged, and an inspection result is returned.
And during the verification, the verification results of all the verifiers are collected and stored in a unified manner according to the HibernateValidator mode.
Step S31 constructs a dynamic verifier class by using ASM technology according to the configuration of the verification assembly parent class through a built-in dynamic verification construction class, including:
s311: according to the unique class name and the ID information, an ASM interface is called to generate the dynamic class, and a related method of reading and writing the dynamic class byte code is obtained;
s312: writing byte codes of a parameter-free private construction method in the dynamic class;
s313: writing byte codes of a static single instance method in the dynamic class;
s314: writing byte codes for realizing a verification method for verifying the assembly parent class into the dynamic class;
s3141: acquiring annotation information, data types and values of all attribute members through reflection; traversing each attribute member;
s3142: the attribute is a member class definition, and byte codes do not need to be generated and skipped;
s3143: if the attribute does not have the service check annotation, no byte code is required to be generated, and skipping is performed;
s3144: the attribute has a conditional check note decoding function, and then a check method conditional judgment byte code of the attribute is generated;
s31441: generating byte codes for judging that the attribute value meets the condition checking logic;
s31442: generating check byte codes which do not meet the conditions;
s3145: the attribute has nested check comments, which indicates that the attribute is a complex data type and check logic is required to be dynamically generated; generating a dynamic verification class of the attribute, and declaring a static instance of the dynamic verification class as a static attribute of the dynamic verification class;
s3146: the attribute is a set of set types and has nested verification notes, a dynamic verification method class of the set type attribute is required to be generated, and a static instance of the dynamic verification method class is declared to be a static attribute of the dynamic verification class;
s3147, each attribute with verification annotation needs to generate byte codes of an attribute verification method; if the attribute declares the static instance of the dynamic verification class involved in S3145 or S3146, a verification method of the static instance is used in the attribute verification method; if the attribute is a common verification annotation, the verification method of the attribute uses a verification method of a native verifier class HibernateValidator; if the attribute also has a condition verification annotation, only part of the condition verification logic is satisfied to generate a byte code for calling a static instance or a verification method of the HibernateValidator; the part which does not meet the condition does not generate byte codes for calling the checking method;
s3148: judging whether the parameter type has a parent class or not after the attribute is traversed, generating a dynamic verifier code of the parent class if the parameter type has the parent class, and declaring a static instance of the dynamic verifier code as a static attribute of the dynamic verification class; if the parent class does not exist, the parent class is not generated;
s3149: the dynamic verification class verification method sequentially calls the verification methods of the nested annotation attribute, the nested annotation set attribute, the condition annotation attribute and the common verification attribute, and finally calls the verification method of the static instance of the parent class.
On the other hand, the application provides an associated service data verification device based on ASM byte code technology, which comprises the following steps:
the receiving module is used for receiving a verification parameter object of an external request and acquiring Java class of the parameter;
the generation module is used for generating a corresponding dynamic verification unique class name of the Java class according to the package name and class name of the Java class and according to the KEY.FACTORY of the Java class;
the data checking module is used for judging whether the static global handle of the dynamic check class exists or not;
the ASM check byte codes do not exist, and are dynamically generated according to the configuration of the check assembly parent class through the built-in dynamic check construction class;
the dynamic verification class is generated, a static single instance handle of the class is used, a verification method of the dynamic verification class is called, after the ASM dynamic code is completed to carry out logic judgment of an associated field, a HibernateValidator native verifier class is finally called, and verification methods corresponding to other notes on the field are verified; after the inspection is completed, the error code and the error prompt information are packaged, and an inspection result is returned.
In yet another aspect, the present application provides an electronic device, including: the system comprises one or more processors and a storage device, wherein the storage device is used for storing executable instructions which, when executed by the processors, realize the verification method.
In yet another aspect, the present application provides a computer readable storage medium storing computer executable instructions that, when executed, are configured to implement the verification method described above.
In yet another aspect, the present application provides a computer program comprising computer executable instructions which, when executed, are adapted to carry out the verification method described above.
The application has the advantages that:
1) The ASM byte code check class is dynamically generated during use, can be reused after being generated, and has higher calling efficiency; the original Java check logic does not reserve a target check chain of the Java check logic for each parameter type, and reloads the Java check logic for space time exchange when each time of calling check is needed;
2) According to the value of the condition field, dynamically calling a verification method of an internal member or a nested dynamic verification class, and if the condition is not met, not entering a subsequent verification;
3) The native or custom checking method of the multiplex Java technical stack provides a unified entry.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:
FIG. 1 is a class provided by a Java technical stack according to an embodiment of the present application;
FIG. 2 is a verification flow chart of an embodiment of the present application;
FIG. 3 is a flow chart of dynamic check byte code generation according to an embodiment of the present application.
Detailed Description
Embodiments of the present application will be described in detail below with reference to the accompanying drawings.
The class provided by the Java technical stack according to the embodiment of the application is shown in FIG. 1, wherein:
verifying and assembling a parent class BeanValidator: providing a checking interface, interface realization and byte code definition configuration of an internal method of a general ASM dynamic checker, defining a new error code format, and constructing an internal static class of the dynamic checking class;
dynamic check structure class Generator: realizing ASM dynamic checking class byte code generation class;
condition check annotation class V: defining annotation class needing condition field association check;
the dynamic verifier class cgilib$beanvalidate byasm$key: a dynamic verification class generated according to the type of the verification parameter Object, wherein the Key uniquely identifies the class; inheriting the BeanValidator to realize a verification method of the parent class; the check byte code generation help class beanvalidiationsupport: tool classes that help generate bytecodes;
the conditional check class bytecode verifier generator class beanvalidate encoder generator: defining classes of byte code logic of different condition check rules;
the above is a class newly introduced by the Java technical stack in the embodiment of the application.
The following are classes provided by the original Java technology stack, such as the class with gray background in FIG. 1:
dynamic check architecture class abstract creator: the method parent class of the construction class provided by the ASM byte code, and the dynamic verification construction class Generator inherits the class;
the original checker class HibernateValidator and the nested annotation class Valid are used to multiplex the mechanism of the original Hibernate checker.
As shown in fig. 2, the present application provides a related service data verification method based on ASM byte code technology, which includes:
step S1: receiving a verification parameter object of an external request, and acquiring a Java class of the parameter;
step S2: generating a corresponding dynamic check unique class name of the Java class according to the packet name and class name of the Java class and according to the KEY.FACTORY of the Java class;
step S3: judging whether the static global handle of the dynamic verification class exists or not;
step S31: the method comprises the steps that a dynamic calibrator class is built by an ASM technology according to the configuration of a calibration assembly parent class through a built-in dynamic calibration construction class;
step S32: the dynamic verification class is generated, a static single instance handle of the class is used, a verification method of the dynamic verification class is called, after the ASM dynamic code is completed to carry out logic judgment of an associated field, a HibernateValidator native verifier class is finally called, and verification methods corresponding to other notes on the field are verified; after the inspection is completed, the error code and the error prompt information are packaged, and an inspection result is returned.
And during the verification, the verification results of all the verifiers are collected and stored in a unified manner according to the HibernateValidator mode.
As shown in fig. 3, the step S31 constructs a dynamic verifier class by using ASM technology according to the configuration of the verification assembly parent class through a built-in dynamic verification construction class, including:
s311: according to the unique class name and the ID information, an ASM interface is called to generate the dynamic class, and a related method of reading and writing the dynamic class byte code is obtained;
s312: writing byte codes of a parameter-free private construction method in the dynamic class;
s313: writing byte codes of a static single instance method in the dynamic class;
s314: writing byte codes for realizing a verification method for verifying the assembly parent class into the dynamic class;
s3141: acquiring annotation information, data types and values of all attribute members through reflection; traversing each attribute member;
s3142: the attribute is a member class definition, byte codes are not required to be generated, and skipping is performed;
s3143: the attribute has no business check annotation, no byte code is required to be generated, and the attribute is skipped;
s3144: the attribute has a conditional check note decoding function, and a check method conditional judgment byte code of the attribute is generated;
s31441: generating byte codes for judging that the attribute value meets the condition checking logic;
s31442: generating check byte codes which do not meet the conditions;
s3145: the attribute has nested check comments, which indicates that the attribute is a complex data type, and check logic is dynamically generated; generating a dynamic verification class of the attribute, and declaring a static instance of the dynamic verification class as a static attribute of the dynamic verification class;
s3146: the attribute is a set of set types and has nested verification annotations, a dynamic verification method class of the set type attribute is generated, and a static instance of the dynamic verification method class is declared as a static attribute of the dynamic verification class;
s3147, each attribute with verification annotation needs to generate byte codes of an attribute verification method; if the attribute declares the static instance of the dynamic verification class involved in S3145 or S3146, a verification method of the static instance is used in the attribute verification method; if the attribute is a common verification annotation, the verification method of the attribute uses a verification method of a native verifier class HibernateValidator; if the attribute also has a condition verification annotation, only part of the condition verification logic is satisfied to generate a byte code for calling a static instance or a verification method of the HibernateValidator; the part which does not meet the condition does not generate byte codes for calling the checking method;
s3148: judging whether the parameter type has a parent class or not after the attribute is traversed, generating a dynamic verifier code of the parent class if the parameter type has the parent class, and declaring a static instance of the dynamic verifier code as a static attribute of the dynamic verification class; if the parent class does not exist, the parent class is not generated;
s3149: the dynamic verification class verification method sequentially calls the verification methods of the nested annotation attribute, the nested annotation set attribute, the condition annotation attribute and the common verification attribute, and finally calls the verification method of the static instance of the parent class.
A RootBean is a subclass of inheriting ParentBean, and also includes a member variable child of the child Bean type, and a member variable child of the set List < child Bean > type, and a member variable rootName of the common String type.
The specific embodiment of the application is as follows:
1) Firstly calling a validate method using a BeanValidater tool class, starting generation of an ASM byte code dynamic check class, and inheriting the BeanValidater by the check class and rewriting the validate method;
2) The Generator built in the BeanValidator firstly obtains the KEY value of the RootBean as ca2c5a9f, and the dynamic verification class name corresponding to the RootBean is cgilib$BeanValidator ByASM$ca 2c5a9;
3) Static member construction is performed: searching comments of member variables of the RootBean class, finding that the child member variable has a V condition check comment, taking effect when the value of a related field rootName is not null and the maximum length is not more than 5, nesting comments with Valid, and collecting member variables child to have a Valid check comment and a parent class; thus, when constructing, generating corresponding dynamic check class and obtaining its static instance as internal attribute, the attribute name is
childValidator,chidrenValidator,superValidator；
4) The internal method structure is carried out: for each member variable, generating a logical byte code of a check processing method of the member variable, wherein the method is named as rootName $validate (), child validate ();
5) Rewriting a validate () method, calling the method in sequence, and finally calling the validate method of the parent class; the method comprises the following specific steps:
a) Adding the verification judgment of the associated field, which is completed by the BeanValidator support class, into a byte code verification method child $validate corresponding to the field child with the condition judgment annotation V; when the value conforming to the rootName is not null and the maximum length is not more than 5, the nesting check on child is executed by
The BeanValidator support calls the child Validator for verification;
b) Traversing the set member of the field in a byte code verification method corresponding to the child of the set member variable and nested verification annotation, and calling the child validator by the BeanValidator support to verify each element of the set;
c) For a common member variable rootName without special comments, directly calling a HibernateValidator contained in the BeanValiator for verification;
d) After all member variables are verified, calling a validate method of a dynamic verification class instance supervalidater of the parent class, and verifying each field of the parent class;
6) Checking between dynamic checking classes through a nested member variable and a valid method thereof;
7) In the ParentBean example, the member rootName is 'myrootname', is not null, but the maximum field length exceeds 5, and a verification method of a dynamic verification class child of the member variable of the child bean is not called; if the member rootName in the ParentBean instance is "abc", a verification method of the child validder is called, so that the verification chains are different according to different field values;
8) The BeanValidator support class helps the error information of the nested dynamic verification class to be handled uniformly by the root dynamic verifier cgilib$BeanValidator ByASM$ca 2c5a 9.
In this embodiment, three dynamic check classes are generated in the memory, only common check comments are included in the child bean and the Parentbean, and a check method is constructed for each field by referring to the rootName$validate in the previous example.
The application uses ASM byte code technology, uses built-in handle to multiplex original annotation checker of open source hibernate, and uses byte code to reconstruct judgment process of annotation condition check. For each parameter data class and its nested and aggregated attributes, different dynamic verification class entries are generated. And (3) according to the actual value of the associated attribute, different target check links are walked according to the generated byte codes of the ASM by using the same type of different parameter examples.
The application solves the problems of verification of the related elements of the service data during operation, in particular to the situations that the related elements have different values and the related element verification rules are different. Meanwhile, when new verification processing is introduced, the original annotation type verification mode can be reused, and the verification entry calling form is unchanged.
The above description is only of the preferred embodiments of the present application and is not intended to limit the present application, and various modifications and variations may be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.
Claims (6)
1. An associated service data verification method based on ASM byte code technology comprises the following steps:
step S1: receiving a verification parameter object of an external request, and acquiring a Java class of the parameter;
step S2: generating a corresponding dynamic check unique class name of the Java class according to the packet name and class name of the Java class and according to the KEY.FACTORY of the Java class;
step S3: judging whether the static global handle of the dynamic verification class exists or not;
step S31: the method comprises the steps that a dynamic calibrator class is built by an ASM technology according to the configuration of a calibration assembly parent class through a built-in dynamic calibration construction class;
step S32: the dynamic verification class is generated, a static single instance handle of the class is used, a verification method of the dynamic verification class is called, after the ASM dynamic code is completed to carry out logic judgment of an associated field, a HibernateValidator verifier is finally called, and verification methods corresponding to other notes on the field are verified; after the inspection is completed, the error code and the error prompt information are packaged, and an inspection result is returned.
2. The ASM byte code technology based associated service data verification method of claim 1, wherein: step S31 constructs a dynamic verifier class by using ASM technology according to the configuration of the verification assembly parent class through a built-in dynamic verification construction class, including:
s311: according to the unique class name and the ID information, an ASM interface is called to generate the dynamic class, and a related method of reading and writing the dynamic class byte code is obtained;
s312: writing byte codes of a parameter-free private construction method in the dynamic class;
s313: writing byte codes of a static single instance method in the dynamic class;
s314: writing byte codes for realizing a verification method for verifying the assembly parent class into the dynamic class;
s3141: acquiring annotation information, data types and values of all attribute members through reflection; traversing each attribute member;
s3142: the attribute is a member class definition, byte codes are not required to be generated, and skipping is performed;
s3143: the attribute has no business check annotation, no byte code is required to be generated, and the attribute is skipped;
s3144: the attribute has a conditional check note decoding function, and then a check method conditional judgment byte code of the attribute is generated;
s31441: generating byte codes for judging that the attribute value meets the condition checking logic;
s31442: generating check byte codes which do not meet the conditions;
s3145: the attribute has nested check-annotation decoding, which means that the attribute is a complex data type and check logic is dynamically generated; generating a dynamic verification class of the attribute, and declaring a static instance of the dynamic verification class as a static attribute of the dynamic verification class;
s3146: the attribute is a set of set types and has nested check comments, a dynamic check class of the set type attribute is generated, and a static instance of the dynamic check class is declared as a static attribute of the dynamic check class;
s3147, each attribute with verification annotation needs to generate byte codes of an attribute verification method; if the attribute declares the static instance of the dynamic verification class involved in S3145 or S3146, a verification method of the static instance is used in the attribute verification method; if the attribute is a common verification annotation, the verification method of the attribute uses a verification method of a native verifier class HibernateValidator; if the attribute also has a condition verification annotation, only part of the condition verification logic is satisfied to generate a byte code for calling a static instance or a verification method of the HibernateValidator; the part which does not meet the condition does not generate byte codes for calling the checking method;
s3148: judging whether the parameter type has a parent class or not after the attribute is traversed, generating a dynamic verifier code of the parent class if the parameter type has the parent class, and declaring a static instance of the dynamic verifier code as a static attribute of the dynamic verification class; if the parent class does not exist, the parent class is not generated;
s3149: the dynamic verification class verification method sequentially calls the verification methods of the nested annotation attribute, the nested annotation set attribute, the condition annotation attribute and the common verification attribute, and finally calls the verification method of the static instance of the parent class.
3. The ASM byte code technology based associated service data verification method of claim 1, wherein: in the step S32, the verification results of each verifier are collected and stored in a unified manner according to the HibernateValidator mode during verification.
4. An ASM bytecode technology-based associated service data verification device, comprising:
the receiving module is used for receiving a verification parameter object of an external request and acquiring Java class of the parameter;
the generation module is used for generating a corresponding dynamic verification unique class name of the Java class according to the package name and class name of the Java class and according to the KEY.FACTORY of the Java class;
the data checking module is used for judging whether the static global handle of the dynamic check class exists or not;
the ASM check byte codes are dynamically generated according to the configuration of the check assembly base class through the built-in dynamic check construction class;
the dynamic verification class is generated, a static single instance handle of the class is used, a verification method of the dynamic verification class is called, after the ASM dynamic code is completed to carry out logic judgment of an associated field, a HibernateValidator verifier is finally called, and verification methods corresponding to other notes on the field are verified; after the inspection is completed, the error code and the error prompt information are packaged, and an inspection result is returned.
5. An electronic device, comprising:
one or more processors; and
a memory device for storing executable instructions, characterized by: the executable instructions, when executed by the processor, implement the steps of the associated service data verification method based on ASM bytecode technology of any one of claims 1-3.
6. A computer-readable storage medium having stored thereon computer-executable instructions, characterized in that: the instructions when executed for implementing the steps of the ASM byte code technology based associated service data verification method of any one of claims 1-3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311132025.2A CN117076328A (en) | 2023-09-04 | 2023-09-04 | Associated service data verification method and device based on ASM byte code technology |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311132025.2A CN117076328A (en) | 2023-09-04 | 2023-09-04 | Associated service data verification method and device based on ASM byte code technology |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117076328A true CN117076328A (en) | 2023-11-17 |
Family
ID=88702284
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311132025.2A Pending CN117076328A (en) | 2023-09-04 | 2023-09-04 | Associated service data verification method and device based on ASM byte code technology |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117076328A (en) |
-
2023
- 2023-09-04 CN CN202311132025.2A patent/CN117076328A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20140372968A1 (en) | Software modeling framework | |
| US8285676B2 (en) | Containment agnostic, N-ary roots leveraged model synchronization | |
| CN102929680A (en) | Method, device and system for converting a testing and test control notation version 3 (TTCN-3) script into a Java source code | |
| CN111427578B (en) | Data conversion method, device and equipment | |
| CN111179086A (en) | Intelligent contract virtual machine based on WebAssembly | |
| Khatchadourian et al. | Pointcut rejuvenation: Recovering pointcut expressions in evolving aspect-oriented software | |
| Lasser et al. | A verified LL (1) parser generator | |
| CN111240772B (en) | Block chain-based data processing method, device and storage medium | |
| US8606766B2 (en) | Method and system to handle java class versioning | |
| US10606569B2 (en) | Declarative configuration elements | |
| Xu et al. | A model-based approach to test generation for aspect-oriented programs | |
| Otto et al. | A flow graph based approach for controlled generation of AAS digital twin instances for the verification of compliance check tools | |
| CN117076328A (en) | Associated service data verification method and device based on ASM byte code technology | |
| CN115022312A (en) | Method and device for realizing multiple intelligent contract engines, electronic equipment and storage medium | |
| US20070174823A1 (en) | Compile-time interpretable code error detection | |
| Bauml et al. | Reconstruction of type information from java bytecode for component compatibility | |
| CN115586904B (en) | JSON data format description-based dynamic generation method for Java beans | |
| Doan et al. | Towards Contract Modules for the Tezos Blockchain (Short Paper) | |
| CN114579135B (en) | Installation package generation method and device | |
| Maschotta et al. | An OCL Implementation for Model-Driven Engineering of C++ | |
| US11909858B1 (en) | System and method for generating and performing a smart contract | |
| Garcia-Dominguez et al. | Models from Code or Code as a Model? | |
| GB2412765A (en) | Compiled document type definition verifier | |
| Ribeiro | Invariant-Driven Automated Testing | |
| CN115964075A (en) | Application export and import method and device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |