CN114564280A

CN114564280A - Method and system for realizing software package by dynamically loading interface during running

Info

Publication number: CN114564280A
Application number: CN202210119052.5A
Authority: CN
Inventors: 姜伟斌; 杨建国
Original assignee: Beijing Time Zhengbang Technology Co ltd
Current assignee: Beijing Time Zhengbang Technology Co ltd
Priority date: 2022-02-08
Filing date: 2022-02-08
Publication date: 2022-05-31

Abstract

The application provides a method for realizing a software package by dynamically loading an interface during running, which comprises the following steps: starting a container service listener, wherein the container service listener monitors the creation and destruction of a context object; the dynamic service management acquires plug-ins of a database to be loaded and/or unloaded; and the plug-in manager loads the interface service jar needing to be loaded into the class path or unloads the interface service jar needing to be unloaded from the class path. The realization classes of the software program are separated from the release packet, different realization classes are respectively packaged, and dynamic loading or unloading is carried out through the dynamic loading program, so that the aim of adding or updating the realization classes without stopping or restarting is fulfilled.

Description

Method and system for realizing software package by dynamically loading interface during running

Technical Field

The application belongs to the technical field of computers, and particularly relates to a method and a system for realizing a software package by dynamically loading an interface during running.

Background

At present, most software programs generally pack and issue an interface and an implementation class when the interface has a plurality of implementation classes, and have the defect that the interface and the implementation class need to be repackaged and issued after an issuing package is deployed and produced and if the implementation class is newly added. In some special cases, the system needs a dynamic loading or hot plug mode to add or update the implementation class, and cannot stop (not close the application) to reissue the version.

In view of this, it is very meaningful to provide a method and a system for implementing a software package by a runtime dynamic loading interface.

Content of application

In order to solve the problem that the version update of the existing software program needs to be realized by dynamic loading, the application provides a method and a system for realizing a software package by a dynamic loading interface during running, so as to solve the existing technical defect problem.

In a first aspect, the present application provides a method for implementing a software package by dynamically loading an interface during runtime, where the method includes:

starting a container service listener, wherein the container service listener monitors the creation and destruction of the context object;

the method comprises the steps that dynamic service management obtains plug-ins needing to be loaded and/or unloaded in a database;

and the plug-in manager loads the interface service jar required to be loaded into the class path or unloads the interface service jar required to be unloaded from the class path.

The realization classes of the software program are separated from the release packet, different realization classes are respectively packaged, and dynamic loading or unloading is carried out through the dynamic loading program, so that the aim of adding or updating the realization classes without stopping or restarting is fulfilled.

Preferably, the dynamic service management further comprises upgrade management of plug-ins.

Further preferably, the container service listener implements listening based on a Spring framework setting.

Further preferably, the plug-in manager further comprises a reference to maintain a version package, a class loader, and an annotation context.

Further preferably, the class loader creates a class load specific to itself, and loads jar into the class path.

Preferably, the dynamic service management further comprises:

configuring a required database;

the front end calling instruction starts a request service according to the format parameters to acquire the configuration of the plug-in and judges whether the plug-in is newly added or upgraded;

if the acquired plug-in is upgraded or newly added, the dynamic service management is started;

and if the acquired plug-in is not newly added or upgraded, the back-end instruction starts the analysis of the factory policy service, acquires the required dynamic service and calls the start. Under the condition that the interface is not changed, a new interface implementation package can be uploaded and dynamically loaded, so that the new interface implementation class can be used in the system, and the requirement of upgrading the function without stopping the machine can be met.

Further preferably, the parsing and acquiring the required dynamic service further includes: judging whether the dynamic service is cached or not;

if so, acquiring a cache result;

Otherwise, returning the dynamic service result.

In a second aspect, the present application further provides a system for implementing a software package by a runtime dynamic loading interface, including:

a container service monitoring module: configuring and monitoring the creation and destruction of the context object;

the dynamic service management module: configuring a load, unload and upgrade for the management plug-in;

a plug-in management module: configuring a dynamic management interface to realize loading and unloading of jar packages, and maintaining references of version packages, class loaders and annotation contexts;

class loader module: configuring a class loader for realizing self-specification, and loading jar into a class path;

a judging module: the configuration is used for judging whether the plug-in is upgraded or newly added or not and judging whether the dynamic service is cached or not;

a cache module: configured to cache the required data.

In a third aspect, an embodiment of the present application provides an electronic device, including: one or more processors; storage means for storing one or more programs which, when executed by one or more processors, cause the one or more processors to carry out a method as described in any one of the implementations of the first aspect.

In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements the method as described in any implementation manner of the first aspect.

Compared with the prior art, the beneficial results of this application lie in:

(1) the realization classes of the software program are separated from the release packet, different realization classes are respectively packaged, and dynamic loading or unloading is carried out through the dynamic loading program, so that the aim of adding or updating the realization classes without stopping or restarting is fulfilled.

(2) Under the condition that the interface is not changed, a new interface implementation package can be uploaded and dynamically loaded, so that the new interface implementation class can be used in the system, and the requirement of upgrading the function without stopping the machine can be met.

Drawings

The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and together with the description serve to explain the principles of the application. Other embodiments and many of the intended advantages of embodiments will be readily appreciated as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.

FIG. 1 is an exemplary device architecture diagram in which one embodiment of the present application may be applied;

FIG. 2 is a schematic overall flowchart of a method for implementing a software package by a runtime dynamic loading interface according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating a method for implementing a software package by a runtime dynamic load interface according to an embodiment of the present application;

fig. 4 is a schematic flowchart of S2 in the method for implementing a software package by a runtime dynamic load interface according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a system implementing a software package for a runtime dynamic load interface according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a computer device suitable for implementing an electronic apparatus according to an embodiment of the present application.

Detailed Description

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the application may be practiced. In this regard, directional terminology, such as "top," "bottom," "left," "right," "up," "down," etc., is used with reference to the orientation of the figure(s) being described. Because components of embodiments can be positioned in a number of different orientations, the directional terminology is used for purposes of illustration and is in no way limiting. It is to be understood that other embodiments may be utilized and logical changes may be made without departing from the scope of the present application. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present application is defined by the appended claims.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for an implementation.

Fig. 1 illustrates an exemplary system architecture 100 to which a method for processing information or an apparatus for processing information of embodiments of the present application may be applied.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like. The

terminal devices

101, 102, 103 may have various communication client applications installed thereon, such as a web browser application, a shopping application, a search application, an instant messaging tool, a mailbox client, social platform software, and the like.

The

terminal devices

101, 102, 103 may be various electronic devices having communication functions, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 105 may be a server that provides various services, such as a background information processing server that processes check request information transmitted by the

terminal apparatuses

101, 102, 103. The background information processing server may analyze and perform other processing on the received verification request information, and obtain a processing result (e.g., verification success information used to represent that the verification request is a legal request).

It should be noted that the method for processing information provided in the embodiment of the present application is generally performed by the server 105, and accordingly, the apparatus for processing information is generally disposed in the server 105. In addition, the method for sending information provided by the embodiment of the present application is generally executed by the

terminal equipment

101, 102, 103, and accordingly, the apparatus for sending information is generally disposed in the

terminal equipment

101, 102, 103.

The server may be hardware or software. When the server is hardware, it may be implemented as a distributed server cluster formed by multiple servers, or may be implemented as a single server. When the server is software, it may be implemented as multiple pieces or modules (e.g., to provide distributed services), or as a single piece or module. And is not particularly limited herein.

In a first aspect, fig. 2 illustrates a method for implementing a software package by a runtime dynamic loading interface disclosed in an embodiment of the present application, and as shown in fig. 2 and fig. 3, the method includes:

s1, starting a container service monitor, wherein the container service monitor monitors the creation and destruction of the context object;

specifically, in this embodiment, the container service listener constructs a Spring context container based on a Spring framework, and implements monitoring on a context object.

S2, dynamic service management acquires the plug-in unit to be loaded and/or unloaded of the database;

referring to fig. 2 and 3, in this embodiment, the dynamic service management further includes:

s21, configuring a required database;

s22, the front end calling instruction starts a request service according to the format parameters to obtain the configuration of the plug-in, and judges whether the plug-in is newly added or upgraded;

if the acquired plug-in is upgraded or newly added, dynamic service management is started;

and if the acquired plug-in is not newly added or upgraded, the back-end instruction starts the analysis of the factory policy service, acquires the required dynamic service and calls the start.

Specifically, the analyzing and acquiring the required dynamic service further includes:

judging whether the dynamic service is cached or not;

if so, acquiring a cache result;

Otherwise, returning a dynamic service result.

In this embodiment, dynamic service management includes managing the loading, unloading, and upgrading of plug-ins.

S3, the plug-in manager loads the interface service jar to be loaded into the class path or unloads the interface service jar to be unloaded from the class path.

In particular, the plug-in manager also includes references to maintain version packages, class loaders, and annotation contexts. In this embodiment, the class loader creates its own specific class load, loading jar into the class path.

When a program actively uses a certain class, if the class is not loaded in the memory, the JVM initializes the class through 3 steps of loading, connecting and initializing. If there is no accident, the JVM will complete 3 steps consecutively, so sometimes these 3 steps are also referred to collectively as class loading or class initialization. Loading refers to reading a class file of a class into a memory and creating a java. The loading of classes is done by class loaders, which are usually provided by the JVM, which are also the basis for all the previous programs to run, and these class loaders provided by the JVM are usually called system class loaders.

the container service listening module 51: configuring for listening for creation and destruction of context objects;

the dynamic service management module 52: configuring a load, unload and upgrade for the management plug-in;

the plug-in management module 53: configuring a dynamic management interface to realize loading and unloading of jar packages, and maintaining references of version packages, class loaders and annotation contexts;

class loader module 54: configuring a class loader for realizing self-specification, and loading jar into a class path;

the judging module 55: the configuration is used for judging whether the plug-in is upgraded or newly added or not and judging whether the dynamic service is cached or not;

the caching module 56: configured to cache the required data.

According to the technical scheme, the implementation classes of the software program are separated from the release package, different implementation classes are packaged respectively, dynamic loading or unloading is carried out through the dynamic loading program, the purpose that the implementation classes can be newly added or updated without shutdown or restart is achieved, the new interface implementation package can be uploaded under the condition that the interface is not changed, the dynamic loading program is dynamically loaded, the new interface implementation classes can be used in the system, and the requirement of upgrading functions without shutdown can be met.

Reference is now made to fig. 6, which is a schematic diagram illustrating a computer device 600 suitable for implementing an electronic device (e.g., the server or the terminal device shown in fig. 1) according to an embodiment of the present application. The electronic device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the use range of the embodiment of the present application.

As shown in fig. 6, the computer apparatus 600 includes a Central Processing Unit (CPU)601 and a Graphics Processing Unit (GPU)602, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)603 or a program loaded from a storage section 609 into a Random Access Memory (RAM) 606. In the RAM 604, various programs and data necessary for the operation of the apparatus 600 are also stored. The CPU 601, GPU602, ROM 603, and RAM 604 are connected to each other via a bus 605. An input/output (I/O) interface 606 is also connected to bus 605.

The following components are connected to the I/O interface 606: an input portion 607 including a keyboard, a mouse, and the like; an output section 608 including a display such as a Liquid Crystal Display (LCD) and a speaker; a storage section 609 including a hard disk and the like; and a communication section 610 including a network interface card such as a LAN card, a modem, or the like. The communication section 610 performs communication processing via a network such as the internet. The driver 611 may also be connected to the I/O interface 606 as needed. A removable medium 612 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 611 as necessary, so that a computer program read out therefrom is mounted into the storage section 609 as necessary.

In particular, the processes described above with reference to the flow diagrams may be implemented as computer software programs, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer-readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via the communication section 610, and/or installed from the removable media 612. The computer program performs the above-described functions defined in the method of the present application when executed by a Central Processing Unit (CPU)601 and a Graphics Processor (GPU) 602.

It should be noted that the computer readable medium described herein can be a computer readable signal medium or a computer readable medium or any combination of the two. The computer readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor device, apparatus, or any combination of the foregoing. More specific examples of the computer readable medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution apparatus, device, or apparatus. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution apparatus, device, or apparatus. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based devices that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present application may be implemented by software or hardware. The modules described may also be provided in a processor.

As another aspect, the present application also provides a computer-readable medium, which may be contained in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, enable the electronic device to perform the method for runtime dynamic loading interface implementation of the software package.

The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention herein disclosed is not limited to the particular combination of features described above, but also encompasses other arrangements formed by any combination of the above features or their equivalents without departing from the spirit of the invention. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.

Claims

1. A method for realizing software package by a runtime dynamic loading interface is characterized in that the method comprises the following steps:

2. The method for runtime dynamic loading interface to implement a software package of claim 1, wherein the dynamic service management further comprises upgrade management for plug-ins.

3. The method for implementing a software package according to claim 2, wherein the container service listener implements listening based on a Spring framework setting.

4. The method for runtime dynamic loading interface to implement a software package of claim 3, wherein the plug-in manager further comprises a reference to maintain a version package, a class loader, and an annotation context.

5. The method for implementing a software package according to claim 4, wherein the class loader creates a class load specific to itself and loads jar into the class path.

6. The method for runtime dynamic loading of software packages according to claim 1, wherein said dynamic service management further comprises:

configuring a required database;

the front end calling instruction starts a request service according to the format parameters to obtain the configuration of the plug-in and judges whether the plug-in is newly added or upgraded;

and if the acquired plug-in is not newly added or upgraded, the back end commands start the factory policy service analysis, acquire the required dynamic service and call the start.

7. The method for implementing a software package according to claim 6, wherein parsing and obtaining the required dynamic service further comprises: judging whether the dynamic service is cached or not;

if so, acquiring a cache result;

otherwise, returning the dynamic service result.

8. A system for implementing a software package with a runtime dynamic load interface, comprising:

the container service monitoring module: configuring and monitoring the creation and destruction of the context object;

a cache module: configured to cache the required data.

9. An electronic device, comprising:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-7.