A method and apparatus for application deployment, electronic device, and storage medium
By constructing a directed acyclic graph and generating containerless deployment units, the problem of slow startup and high memory consumption of Spring applications is solved, achieving fast startup and low memory consumption, which is suitable for serverless and edge devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA BANKNOTE PRINTING & MINTING
- Filing Date
- 2026-04-10
- Publication Date
- 2026-07-10
AI Technical Summary
Traditional Spring applications are slow to start and consume a lot of memory, making them difficult to adapt to Serverless cloud-native scenarios. GraalVM native image compilation does not fundamentally solve the memory overhead problem, and JVM checkpoint recovery technology has the problems of strong environment dependency and high storage cost.
The runtime state analysis engine obtains the object instance state and dependencies of the Spring application, constructs a directed acyclic graph, generates application code that does not depend on the Spring container, transforms dependency injection and AOP logic into explicit code, and compiles it into a containerless deployment unit.
It enables Spring applications to start up quickly, consume little memory, and have high environmental adaptability, making it suitable for serverless platforms and edge devices.
Smart Images
Figure CN122363715A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically, to an application deployment method, apparatus, electronic device, and storage medium. Background Technology
[0002] Traditional Spring applications require a complex startup process involving classpath scanning, BeanDefinition construction, dependency injection, and AOP (Aspect-Oriented Programming) proxying via an IoC (Inversion of Control) container. This results in slow startup speeds, high memory consumption, and difficulty adapting to cloud-native scenarios like Serverless computing, which demand rapid startup and low resource consumption, due to their reliance on container runtime. While GraalVM (Graal Virtual Machine) native image compilation improves startup speed, it still retains container logic, failing to fundamentally address memory overhead. JVM (Java Virtual Machine) checkpoint recovery technology, on the other hand, suffers from strong environment dependencies and high storage costs.
[0003] Therefore, how to achieve fast startup, low memory usage, and high environment adaptability of Spring applications without relying on the Spring container is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention
[0004] The purpose of this application is to provide an application deployment method, device, electronic device, and storage medium that achieves fast startup, low memory consumption, and high environment adaptability of Spring applications without relying on the Spring container.
[0005] To achieve the above objectives, this application provides an application deployment method, comprising: Run the target Spring application until all objects have been instantiated and dependency injection has been completed. By connecting to the Spring application in the initialization completed state through the runtime state analysis engine, the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances can be obtained. A topology is constructed based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances to describe the dependencies between the object instances. The application code is generated using a containerless application code generator based on the topology, the runtime state of all the object instances, and the aspect logic of aspect-oriented programming. The application code is compiled to generate a deployment unit that does not depend on the Spring container, and the target application is deployed based on the deployment unit.
[0006] The aspect logic for obtaining object instances in aspect-oriented programming includes: The aspect-oriented programming (AOP) annotations on the class or methods of the object instance are analyzed, and the advice logic corresponding to the AOP annotations is parsed using bytecode tools as the aspect logic for the object instance's AOP.
[0007] Among these, obtaining the dependencies between object instances includes: By scanning all fields of the object instance using reflection, the target fields containing dependency injection annotations are identified. Obtain other object instances referenced by the target field at runtime to determine the dependencies between object instances.
[0008] The construction of a topology describing the dependencies between object instances, based on the runtime states of all object instances, aspect logic of aspect-oriented programming, and dependencies between object instances, includes: A directed acyclic graph (DAG) is constructed using object instances as nodes and the dependencies between object instances as directed edges. The topological order of each node in the DAG is then determined based on the dependencies between object instances.
[0009] The process of constructing a directed acyclic graph (DAG) using object instances as nodes and dependencies between object instances as directed edges, and determining the topological order of nodes in the DAG based on the dependencies between object instances, further includes: Detect whether there is a circular dependency in the directed acyclic graph; If a circular dependency exists, it is broken based on a preset strategy; wherein the preset strategy includes converting at least one constructor injection in the circular dependency chain into assignment method injection, or refactoring the dependency relationship between object instances.
[0010] In the application code, Spring's dependency injection annotations are converted into explicit dependency transitive based on constructors, and aspect-oriented programming annotations are converted into corresponding explicit code blocks.
[0011] The step of generating application code using a containerless application code generator based on the topology, the runtime state of all object instances, and aspect-oriented programming logic includes: Generate a corresponding Java class for each instance object according to the topological order of the topological structure, and explicitly pass the dependent object instance in the constructor of the Java class; The aspect logic of the object instance in aspect-oriented programming is converted into an explicit code block containing explicit call statements; Generate a main application class containing a main method; wherein the main method contains code that instantiates all object instances sequentially according to the topological order of the directed acyclic graph and establishes object reference relationships.
[0012] To achieve the above objectives, this application provides an application deployment apparatus, comprising: The runtime module is used to run the target Spring application until all object instances have been instantiated and dependency injection has been completed. The acquisition module is used to connect to the Spring application in the initialization completed state through the runtime state analysis engine to obtain the runtime state of all object instances, aspect-oriented programming aspect logic, and dependencies between object instances; The building module is used to construct a topology that describes the dependencies between the object instances based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances. The generation module is used to generate application code based on the topology, the runtime state of all the object instances, and aspect logic of aspect-oriented programming using a containerless application code generator. The deployment module is used to compile the application code to generate a deployment unit that does not depend on the Spring container, and to deploy the target application based on the deployment unit.
[0013] To achieve the above objectives, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the application deployment method described above.
[0014] To achieve the above objectives, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the application deployment method described above.
[0015] The application deployment method provided in this application, after the Spring application completes initialization, captures the runtime state, dependencies, and AOP logic of all object instances through a state analysis engine, and constructs a directed acyclic graph to ensure the accuracy of dependencies and the computability of the initialization order. Subsequently, a containerless code generator, based on the directed acyclic graph and the captured metadata, converts dependency injection into constructor parameter passing, expands AOP dynamic proxy logic into explicit flow control code, and generates application code. This code, after compilation, forms a deployment unit that does not depend on the Spring container. Since the generated application code no longer contains Spring container metadata processing, reflection calls, and dynamic proxy mechanisms, the startup process is simplified to instantiating objects in topological order, thereby significantly shortening startup time. At the same time, there is no need to maintain framework metadata such as BeanDefinition and proxy class caching at runtime, resulting in a significant reduction in memory consumption. Thus, this application achieves fast startup, low memory consumption, and high environment adaptability of Spring applications without relying on the Spring container. This application also discloses a device verification apparatus, an electronic device, a computer-readable storage medium, and a computer program product, which can achieve the same technical effects.
[0016] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description
[0017] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart illustrating an application deployment method according to an exemplary embodiment; Figure 2 This is a structural diagram illustrating an application deployment apparatus according to an exemplary embodiment; Figure 3 This is a structural diagram of an electronic device according to an exemplary embodiment.
[0019] Explanation of reference numerals in the attached figures: S101, Run the target Spring application until all objects have completed instantiation and dependency injection initialization; S102. Connect to the Spring application in the initialization completed state through the runtime state analysis engine to obtain the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependency relationships between object instances; S103. Construct a topology structure to describe the dependencies between the object instances based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances. S104. Use a containerless application code generator to generate application code based on the topology, the runtime state of all the object instances, and the aspect logic of aspect-oriented programming. S105. Compile the application code to generate a deployment unit that does not depend on the Spring container, and deploy the target application based on the deployment unit; 100. Running module; 200. Acquisition Module; 300. Building Modules; 400. Generation Module; 500. Deployment Module; 1. Communication interface; 2. Processor; 3. Memory; 4. Bus system. Detailed Implementation
[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, in the embodiments of this application, "first," "second," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0021] This application discloses an application deployment method that achieves fast startup, low memory usage, and high environment adaptability of Spring applications without relying on a Spring container.
[0022] See Figure 1 A flowchart illustrating an application deployment method according to an exemplary embodiment, such as... Figure 1 As shown, it includes: S101: The target Spring application has completed its initialization status after all objects have been instantiated and dependency injection has been performed. This step aims to ensure that the target Spring application has reached a stable and complete runtime state, meaning that all Beans (object instances) managed by the Spring IoC (Inversion of Control) container have been created and their dependencies have been correctly established through the Dependency Injection mechanism.
[0023] The initialization complete state means that the ApplicationContext has been completely refreshed, and the instantiation, property population, and initialization methods (such as those annotated with @PostConstruct) of singleton beans have all been executed. For example, in a typical web application, the database connection pool may have already been established, and various service and controller beans are ready to handle external requests. This is a prerequisite for accurate state analysis, as it captures the final valid state of the application after all Spring container lifecycle processes, rather than potential, inactive bean definitions on the classpath.
[0024] S102: Connect to the Spring application in the initialization completed state through the runtime state analysis engine to obtain the runtime state of all object instances, aspect logic of aspect-oriented programming, and dependencies between object instances; In this step, the runtime state analysis engine acts as an external proxy, connecting to the running JVM (Java Virtual Machine) process via Java Management Extensions (JMX), JavaAgent, or direct access to the Spring container's ApplicationContext API. Its core task is to delve into and extract information from three key dimensions: 1) Runtime state of object instances: the specific values of each field of the Bean object after dependency injection and initialization; 2) AOP (Aspect-Oriented Programming) aspect logic: identifying which Beans or methods are enhanced by the AOP proxy and resolving the underlying enhancement logic, such as transaction management, logging, or security verification rules; 3) Dependencies between object instances: clarifying the network structure of "who depends on whom" among Beans. Through this step, the dynamically managed, implicit component relationships and behavioral logic within the Spring container are transformed into a clear, processable data model.
[0025] As a feasible implementation method, obtaining the aspect logic of aspect-oriented programming for an object instance includes: analyzing the aspect-oriented programming annotations marked on the class or method of the object instance, and parsing the advice logic corresponding to the aspect-oriented programming annotations as the aspect logic of aspect-oriented programming for the object instance using a bytecode tool.
[0026] In practice, the system first scans the class and methods of object instances, identifying AOP annotations such as `@Transactional` (transaction management) and `@Cacheable` (caching). Then, bytecode tools (such as ASM, Javassist, or Byte Buddy) are used to parse the actual advice logic corresponding to these annotations in the Spring framework. For example, for a method annotated with `@Transactional`, the system parses that the method needs to be executed within the boundaries of a database transaction, including attributes such as transaction propagation behavior and isolation level. Finally, these parsed rules (e.g., "start a transaction before method execution, commit the transaction after normal method execution, and roll back the transaction when an exception is thrown") are captured as the aspect logic of the object instance. This clearly extracts and defines the cross-cutting concern logic that was originally intertwined and executed at runtime through dynamic proxies, laying the foundation for subsequent conversion into explicit code.
[0027] As a feasible implementation method, obtaining the dependency relationship between object instances includes: scanning all fields of the object instance through reflection to identify the target field containing the dependency injection annotation; obtaining other object instances referenced by the target field at runtime to determine the dependency relationship between object instances.
[0028] In practice, for each instantiated Bean, the Java Reflection API is used to traverse all its declared fields (including private fields) to find "target fields" marked with dependency injection annotations, such as @Autowired (autowiring), @Resource (resource injection), or @Inject (injection). The key is that it doesn't just identify the annotations, but directly reads the object references actually held by these fields in the current JVM heap memory through reflection. For example, in the UserService object, a UserRepository type field marked with @Autowired is found, and this field currently points to a specific JdbcUserRepository instance. Through this reference, it can be determined that UserService depends on JdbcUserRepository. This approach accurately captures dependencies that actually take effect due to conditional configurations (such as @Profile and @ConditionalOnProperty), ensuring the accuracy of the generated code dependency graph.
[0029] S103: Construct a topology structure to describe the dependencies between the object instances based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances; This step aims to structurally model the captured dependency information. The topology can be a DAG (Directed Acyclic Graph), a set of vertices and edges where edges are directed and there are no cyclic paths. In this embodiment, nodes represent object instances (e.g., UserService, OrderService, DataSource), and directed edges represent dependency directions; for example, an edge from UserService to UserRepository indicates that the former depends on the latter. Processing this DAG using graph theory algorithms (such as topological sorting) yields a linear sequence of all nodes, where each node follows all its dependent nodes. This topological order is crucial, as it defines the correct order of object instantiation during subsequent code generation, ensuring that when an object is created, its dependent objects are already ready.
[0030] As a feasible implementation method, the construction of a topology structure to describe the dependencies between object instances based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and dependencies between object instances includes: constructing a directed acyclic graph with object instances as nodes and dependencies between object instances as directed edges, and determining the topological order of each node in the directed acyclic graph according to the dependencies between object instances.
[0031] In practice, the system iterates through all object instances and their dependencies, creating a graph node for each instance. For each dependency (e.g., A depends on B), a directed edge is created from node B to node A (because B is a dependency of A and needs to be created first). Then, a topological sort is performed using Kahn's algorithm or Depth-First Search (DFS) to obtain a feasible sequence of instantiations. For example, the sorted result might be: [DataSource, UserRepository, UserService]. This means that when generating code, DataSource must be instantiated first, then passed to the constructor of UserRepository, and finally the UserRepository instance is passed to the constructor of UserService. This process transforms the implicit dependency resolution logic handled by the Spring container into an explicit, computable graph structure.
[0032] As a preferred implementation, after constructing a directed acyclic graph (DAG) using object instances as nodes and dependencies between object instances as directed edges, and determining the topological order of nodes in the DAG based on the dependencies between object instances, the method further includes: detecting whether there is a circular dependency in the DAG; if so, breaking the circular dependency based on a preset strategy; wherein the preset strategy includes converting at least one constructor injection in the circular dependency chain into assignment method injection, or reconstructing the dependencies between object instances.
[0033] Circular dependencies refer to a circular dependency chain formed between multiple object instances, which cannot be handled by topological sorting. In practice, the system uses the Tarjan algorithm or similar methods to detect circular dependencies in the Directed Acyclic Graph (DAG). Once detected, a preset strategy is triggered to automatically break the cycle. Strategy one is to change the constructor injection of a node in the cycle to setter method (assignment method) injection. For example, in the cycle of instance a → instance b → instance c → instance a (where a, b, and c are instances of classes A, B, and C respectively), the definition of C can be modified to change the injection method from constructor parameter to injection via a setA(A a) method after the object graph is basically constructed. Strategy two is to suggest or automatically refactor the code, such as introducing a third-party dependency or merging some functionalities to eliminate the cycle. This mechanism enhances the robustness of the application deployment scheme, enabling it to handle more complex existing Spring application scenarios.
[0034] S104: Generate application code using a containerless application code generator based on the topology, the runtime state of all the object instances, and aspect logic of aspect-oriented programming; In this step, the containerless application code generator receives the structured data (DAG, runtime state, AOP logic) output from the previous steps and applies code generation techniques (such as template engines or abstract syntax tree operations) to create a completely new, functionally equivalent set of application code—pure Java source code. The key characteristic of this code is that it completely omits Spring framework-specific annotations and runtime classes, instead using standard Java syntax to reproduce the original business logic and component relationships. Because the generated application code is a standard Java program, relying only on the JRE (Java Runtime Environment), it possesses strong environment adaptability and can be seamlessly deployed on serverless platforms or edge devices.
[0035] As a feasible implementation method, in the application code, Spring's dependency injection annotations are converted into explicit dependency transitive based on constructors, and aspect-oriented programming annotations are converted into corresponding explicit code blocks.
[0036] In practical implementation, the mapping rules from Spring features to Java code include two aspects: dependency injection transformation and AOP transformation. Dependency injection transformation: For example, a UserService class that originally used `@Autowired` to inject a UserRepository will, in the generated code, no longer have the `@Autowired` annotation in its class definition. Instead, its constructor will explicitly declare a parameter of type UserRepository. When creating a UserService, an instantiated UserRepository object must be passed in. AOP transformation: For example, an updateUser method annotated with `@Transactional` will no longer be a method wrapped in a proxy in the generated code. Instead, the transaction management code block will be explicitly written within the method body. This transformation transforms runtime dynamic proxies and reflection into clear, readable instructions, completely eliminating the dependency on the Spring AOP framework.
[0037] As a feasible implementation, the method of generating application code using a containerless application code generator based on the topology, the runtime state of all object instances, and aspect-oriented programming logic includes: generating a corresponding Java class for each instance object according to the topological order of the directed acyclic graph, and explicitly passing the dependent object instances in the constructor of the Java class; converting the aspect-oriented programming logic of the object instances into an explicit code block containing explicit call statements; generating a main application class containing a main method; wherein the main method contains code that instantiates all object instances sequentially according to the topological order of the directed acyclic graph and establishes object reference relationships.
[0038] In practice, the process begins with generating Bean classes: a corresponding Java class is created for each Bean in the original Spring application. This class has a constructor whose parameter list includes all its dependent objects. Next, the AOP logic is transformed: for methods requiring AOP enhancement, the original method body is replaced with a corresponding explicit code block (such as the transaction code mentioned above) or the original business logic is wrapped in it. Finally, the main class is synthesized: an application entry class containing a main method is generated. Within this main method, a series of object creation and assembly statements are written, strictly following the topological order of the DAG. In this way, an application that originally required a Spring container for assembly and management is transformed into a regular Java program that can be initialized and run independently.
[0039] S105: Compile the application code to generate a deployment unit that does not depend on the Spring container, and deploy the target application based on the deployment unit.
[0040] In this step, the generated application code is compiled into .class files using a standard compiler or build tool, such as javac or Maven, to compile pure Java source code, and then packaged into an executable JAR file. This deployment unit does not contain the Spring framework library, only retaining the business logic code and necessary third-party dependencies (such as database drivers). During deployment, it can be run directly on a server with only a JRE installed using the `java -jar` command, just like any other ordinary Java application. It can also be further packaged into a Docker image or directly deployed to any Java-enabled cloud platform, serverless computing environment, or edge device, achieving lightweight and native-level deployment of Spring applications.
[0041] The application deployment method provided in this application, after the Spring application completes initialization, captures the runtime state, dependencies, and AOP logic of all object instances through a state analysis engine, and constructs a directed acyclic graph to ensure the accuracy of dependencies and the computability of the initialization order. Subsequently, a containerless code generator, based on the directed acyclic graph and the captured metadata, converts dependency injection into constructor parameter passing, expands AOP dynamic proxy logic into explicit flow control code, and generates pure Java code. This code, after compilation, forms a deployment unit that does not depend on the Spring container. Since the generated application code no longer includes Spring container metadata processing, reflection calls, and dynamic proxy mechanisms, the startup process is simplified to instantiating objects in topological order, thereby significantly shortening startup time. At the same time, the runtime does not need to maintain framework metadata such as BeanDefinition and proxy class caching, resulting in a significant reduction in memory consumption. Therefore, this application embodiment achieves fast startup, low memory consumption, and high environment adaptability of Spring applications without relying on the Spring container.
[0042] The following describes an application deployment apparatus provided in an embodiment of this application. The application deployment apparatus described below and the application deployment method described above can be referred to each other.
[0043] See Figure 2 A structural diagram of an application deployment apparatus is shown according to an exemplary embodiment, such as... Figure 2 As shown, it includes: Run module 100, which is used to run the target Spring application until all object instances have completed instantiation and dependency injection initialization. The acquisition module 200 is used to connect to the Spring application in the initialization completed state through the runtime state analysis engine to obtain the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependency relationships between object instances; Module 300 is used to construct a directed acyclic graph describing the dependencies between the object instances based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances. The generation module 400 is used to generate pure Java code based on the directed acyclic graph, the runtime state of all the object instances, and the aspect logic of aspect-oriented programming using a containerless application code generator. Deployment module 500 is used to compile the pure Java code to generate a deployment unit that does not depend on the Spring container, and to deploy the target application based on the deployment unit.
[0044] The application deployment apparatus provided in this application, after the Spring application completes initialization, captures the runtime state, dependencies, and AOP logic of all object instances through a state analysis engine, and constructs a directed acyclic graph to ensure the accuracy of dependencies and the computability of the initialization order. Subsequently, a containerless code generator, based on the directed acyclic graph and the captured metadata, converts dependency injection into constructor parameter passing, expands AOP dynamic proxy logic into explicit flow control code, and generates pure Java code. This code, after compilation, forms a deployment unit that does not depend on the Spring container. Since the generated application code no longer includes Spring container metadata processing, reflection calls, and dynamic proxy mechanisms, the startup process is simplified to instantiating objects in topological order, thereby significantly shortening startup time. At the same time, the runtime does not need to maintain framework metadata such as BeanDefinition and proxy class caching, resulting in a significant reduction in memory consumption. Thus, this application embodiment achieves fast startup, low memory consumption, and high environment adaptability of Spring applications without relying on the Spring container.
[0045] Based on the above embodiments, as a preferred embodiment, the acquisition module 200 includes: The analysis unit is used to analyze the aspect-oriented programming annotations marked on the class or method of the object instance, and to parse the advice logic corresponding to the aspect-oriented programming annotations as aspect logic of the object instance using bytecode tools.
[0046] Based on the above embodiments, as a preferred embodiment, the acquisition module 200 includes: The identification unit is used to scan all fields of the object instance through reflection and identify the target field containing the dependency injection annotation. The determining unit is used to obtain other object instances referenced by the target field at runtime in order to determine the dependencies between object instances.
[0047] Based on the above embodiments, as a preferred implementation, the construction module 300 is specifically used to: construct a directed acyclic graph using object instances as nodes of the directed acyclic graph and the dependencies between object instances as directed edges, and determine the topological order of each node in the directed acyclic graph according to the dependencies between object instances.
[0048] Based on the above embodiments, as a preferred embodiment, it further includes: The detection module is used to detect whether there is a circular dependency in the directed acyclic graph; if so, the circular dependency is broken based on a preset strategy; wherein, the preset strategy includes converting at least one constructor injection in the circular dependency chain into assignment method injection, or reconstructing the dependency relationship between object instances.
[0049] Based on the above embodiments, as a preferred implementation, in the application code, Spring's dependency injection annotations are converted into explicit dependency transitive based on constructors, and aspect-oriented programming annotations are converted into corresponding explicit code blocks.
[0050] Based on the above embodiments, as a preferred implementation, the generation module 400 is specifically used to: generate a corresponding Java class for each instance object according to the topological order of the topological structure, and explicitly pass in the dependent object instance in the constructor of the Java class; convert the aspect logic of the object instance into an explicit code block containing explicit call statements; generate a main application class containing a main method; wherein, the main method contains code that instantiates all object instances sequentially according to the topological order of the directed acyclic graph and establishes object reference relationships.
[0051] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0052] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 3 This is a structural diagram of an electronic device according to an exemplary embodiment, such as... Figure 3 As shown, the electronic device includes: Communication interface 1 enables information exchange with other devices, such as network devices; Processor 2 is connected to communication interface 1 to enable information interaction with other devices and to execute the application deployment methods provided by one or more of the above-mentioned technical solutions when running computer programs. The computer program is stored in memory 3.
[0053] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 3 The general will label all buses as Bus System 4.
[0054] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.
[0055] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or CD-ROM; magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 3 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.
[0056] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.
[0057] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.
[0058] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.
[0059] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.
[0060] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.
[0061] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.
Claims
1. An application deployment method, characterized in that, include: Run the target Spring application until all objects have been instantiated and dependency injection has been completed. By connecting to the Spring application in the initialization completed state through the runtime state analysis engine, the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances can be obtained. A topology is constructed based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances to describe the dependencies between the object instances. The application code is generated using a containerless application code generator based on the topology, the runtime state of all the object instances, and the aspect logic of aspect-oriented programming. The application code is compiled to generate a deployment unit that does not depend on the Spring container, and the target application is deployed based on the deployment unit.
2. The application deployment method according to claim 1, characterized in that, The aspect logic for obtaining object instances in aspect-oriented programming includes: The aspect-oriented programming (AOP) annotations on the class or methods of the object instance are analyzed, and the advice logic corresponding to the AOP annotations is parsed using bytecode tools as the aspect logic for the object instance's AOP.
3. The application deployment method according to claim 1, characterized in that, To obtain the dependencies between object instances, including: By scanning all fields of the object instance using reflection, the target fields containing dependency injection annotations are identified. Obtain other object instances referenced by the target field at runtime to determine the dependencies between object instances.
4. The application deployment method according to claim 1, characterized in that, The topology structure for describing the dependencies between object instances is constructed based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and dependencies between object instances, including: A directed acyclic graph (DAG) is constructed using object instances as nodes and the dependencies between object instances as directed edges. The topological order of each node in the DAG is then determined based on the dependencies between object instances.
5. The application deployment method according to claim 4, characterized in that, After constructing a directed acyclic graph (DAG) using object instances as nodes and dependencies between object instances as directed edges, and determining the topological order of nodes in the DAG based on the dependencies between object instances, the method further includes: Detect whether there is a circular dependency in the directed acyclic graph; If they exist, the circular dependency is broken based on a preset strategy; wherein the preset strategy includes converting at least one constructor injection in the circular dependency chain into assignment method injection, or refactoring the dependency relationship between object instances.
6. The application deployment method according to claim 1, characterized in that, In the application code, Spring's dependency injection annotations are converted into explicit dependency transitive based on constructors, and aspect-oriented programming annotations are converted into corresponding explicit code blocks.
7. The application deployment method according to claim 6, characterized in that, The process of generating application code using a containerless application code generator based on the topology, the runtime state of all the object instances, and aspect logic of aspect-oriented programming includes: Generate a corresponding Java class for each instance object according to the topological order of the topological structure, and explicitly pass the dependent object instance in the constructor of the Java class; The aspect logic of the object instance in aspect-oriented programming is converted into an explicit code block containing explicit call statements; Generate a main application class containing a main method; wherein the main method contains code that instantiates all object instances sequentially according to the topological order of the directed acyclic graph and establishes object reference relationships.
8. An application deployment device, characterized in that, include: The runtime module is used to run the target Spring application until all object instances have been instantiated and dependency injection has been completed. The acquisition module is used to connect to the Spring application in the initialization completed state through the runtime state analysis engine to obtain the runtime state of all object instances, aspect-oriented programming aspect logic, and dependencies between object instances; The building module is used to construct a topology that describes the dependencies between the object instances based on the runtime state of all object instances, aspect logic of aspect-oriented programming, and the dependencies between object instances. The generation module is used to generate application code based on the topology, the runtime state of all the object instances, and aspect logic of aspect-oriented programming using a containerless application code generator. The deployment module is used to compile the application code to generate a deployment unit that does not depend on the Spring container, and to deploy the target application based on the deployment unit.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the application deployment method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the application deployment method as described in any one of claims 1 to 7.