WO2004072821A2 - Systeme et procede d'utilisation de hierarchie de chargeurs de classes pour charger des applications logicielles. - Google Patents

Systeme et procede d'utilisation de hierarchie de chargeurs de classes pour charger des applications logicielles. Download PDF

Info

Publication number
WO2004072821A2
WO2004072821A2 PCT/US2004/004084 US2004004084W WO2004072821A2 WO 2004072821 A2 WO2004072821 A2 WO 2004072821A2 US 2004004084 W US2004004084 W US 2004004084W WO 2004072821 A2 WO2004072821 A2 WO 2004072821A2
Authority
WO
WIPO (PCT)
Prior art keywords
modules
application
classloader
hierarchy
classloaders
Prior art date
Application number
PCT/US2004/004084
Other languages
English (en)
Other versions
WO2004072821A3 (fr
Inventor
Mark Spotswood
Original Assignee
Bea Systems, Inc.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Bea Systems, Inc. filed Critical Bea Systems, Inc.
Publication of WO2004072821A2 publication Critical patent/WO2004072821A2/fr
Publication of WO2004072821A3 publication Critical patent/WO2004072821A3/fr

Links

Classifications

    • 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/445—Program loading or initiating

Definitions

  • the present invention relates generally to computer software application execution, and particularly to a system and method for allowing individual software modules and classloaders to be reloaded in memory without forcing other modules to be reloaded at the same time.
  • Java differs from other programming languages in that programs written in Java are generally run in a virtual machine environment. Once a Java program is written, it may then be compiled into byte-code, interpreted by the Java Virtual Machine (JVM) into hardware instructions, and executed on a variety of different platforms. This methodology allows Java to follow the "write once, run anywhere" paradigm.
  • Components of Java programs are stored in modular components referred to as class files.
  • a class may be defined as a collection of data and methods that operate on that data.
  • a class is able to inherit properties (and methods) from any other class which is found above it in the hierarchy of inter-related classes for a particular program.
  • Classloaders are a fundamental component of the Java language.
  • a classloader is a part of the Java virtual machine (JVM) that loads classes into memory; and is the class responsible for finding and loading class files at run time.
  • JVM Java virtual machine
  • Classloaders are arranged in a hierarchy with parent classloaders and child classloaders. The relationship between parent and child classloaders is analogous to the object relationship of super classes and subclasses.
  • the bootstrap classloader is the root of the Java classloader hierarchy.
  • JVM Java virtual machine
  • JDK Java development kit
  • JDK Java development kit
  • the extensions classloader is a child of the bootstrap classloader.
  • the extensions classloader loads any Java Archive (JAR) files placed in the extensions directory of the JDK. This is a convenient means to extending the JDK without adding entries to the classpath. However, anything in the extensions directory must be self-contained and can only refer to classes in the extensions directory or JDK classes.
  • the system classpath classloader extends the JDK extensions classloader.
  • the system classpath classloader loads the classes from the classpath of the JVM.
  • Application-specific classloaders including, in the case of the BEA WebLogic product, WebLogic Server classloaders) are children of the system classpath classloader.
  • system classloader is used to refer to a type of classloader which is frequently referred to as an "application classloader” in contexts outside of the BEA WebLogic Server product.
  • application classloader is used to differentiate those classloaders from classloaders related to J2EE applications (which BEA WebLogic typically refers to as “application classloaders”).
  • Classloaders typically use a delegation model when loading a class.
  • the classloader implementation first checks to see if the requested class has already been loaded. This class verification improves performance in that the cached memory copy is used instead of repeated loading of a class from disk or permanent storage. If the class is not found in memory, the current classloader asks its parent for the class. Only if the parent cannot load the class does the classloader then attempt to load the class. If a class exists in both the parent and child classloaders, the parent version is loaded. This delegation model is followed to avoid multiple copies of the same form being loaded. Multiple copies of the same class can lead to a ClassCastException.
  • classloaders ask their parent classloaderto load a class before attempting to load the class themselves.
  • classloaders that are associated with Web applications can also be configured to check locally first before asking their parent for the class. This allows Web applications to use their own versions of third-party classes, which might also be used as part of the WebLogic Server product.
  • a second hierarchical configuration loads the majority of the class files required by the application into the root classloader and allows only web modules (commonly packaged as ".WAR" archives) to be loaded by classloaders one level subordinate to the root classloader.
  • This implementation does not address the fact that the set of all modules (for example Enterprise Java Beans or EJBs) utilized by an application is still required to be loaded by a single classloader, and, therefore reloaded as a set.
  • the problems of both of these typical hierarchical organizations include:
  • a module for example an EJB, cannot be reloaded without reloading all classes in the application, which effectively means having to reinitialize (reinit) the entire application.
  • a mechanism that provides more granular control over the classloader hierarchy structure and the associated interrelationships between classes would help address these problems, and give the developer better control over the reloading and namespace separation of individual modules, including EJB's.
  • the present invention provides a system and method for allowing individual software modules to be reloaded in memory without forcing other modules to be reloaded at the same time.
  • Such "reloadable modules” address the problem of not being able to reload a module or component without reloading all classes in the application.
  • the root classloader and webapp classloader levels are reorganized, and the individual implementation classes placed in their own classloader. This allows the developer to define their classloader organization according to their particular needs. In this way the system can reload a component or class without affecting the rest of the application.
  • the developer has the ability to organize the top two levels (i.e. the root and webapp levels) on a per-module basis as they see fit. The third level is organized automatically.
  • a developer can declare the classloader hierarchy in an application deployment descriptor (for example a weblogic-application.xml file) as follows:
  • Figure 1 illustrates a standard classloader structure commonly utilized by applications.
  • Figure 2 illustrates a classloader structure in accordance with one embodiment of the invention.
  • Figure 3 illustrates a classloader hierarchy example in accordance with an embodiment of the invention.
  • Figure 4 illustrates a default classloader hierarchy in accordance with an embodiment of the invention.
  • Figure 5 illustrates a classloader hierarchy generated as a result of parsing a classloader structure in accordance with an embodiment of the invention.
  • Figure 6 is a flowchart showing the steps used to parse a classloader hierarchy in accordance with an embodiment of the invention.
  • Figure 7 illustrates a classloader hierarchy for a simple EJB module in accordance with an embodiment of the invention.
  • Figure 8 is a flowchart showing the steps used to reload EJB implementations in a classloader hierarchy in accordance with an embodiment of the invention.
  • J2EE Java 2 Platform, Enterprise Edition
  • J2EE defines a standard for developing component-based enterprise applications.
  • Enterprise JavaBeans EJBs
  • EJBs allow for development of distributed, portable applications based on Java.
  • JavaServer Page (JSP) components allow for creating web pages that display dynamically-generated content. JSP pages are compiled into servlets and may call EJBs. Additional information about J2EE, EJBs and JSPs can be found in the J2EE specifications published by Sun Microsystems, I nc.
  • the present invention provides a system and method for allowing individual software modules or components, such as J2EE modules, to be reloaded in memory without forcing other modules to be reloaded at the same time.
  • Such "reloadable modules” address the problem of not being able to reload, for example, an EJB without reloading all classes in the application.
  • the root classloader and webapp classloader levels are reorganized, and the individual module (e.g. EJB implementation classes) placed in their own classloader.
  • the system can reload the Enterprise Java Bean (EJB) implementation (impl) class without affecting the rest of the application.
  • the system or a developer can also reload an individual EJB module without affecting the rest of the application.
  • One embodiment of the present invention provides the capability for customization of the classloader hierarchy for use with an application server, such as the WebLogic server product or another type of application server.
  • a deployment descriptor or control file can include a "classloader-structure" stanza which is then interpreted by an application component, such as an application container constructor, either singularly or as recursive nested references to modules and/or individual class files.
  • a hierarchy (a "tree") of associated classloaders is then built.
  • the application server traverses the tree specified in the control file and builds a parent-child relationship between the tiers of selected classloaders, thus establishing the hierarchy.
  • a single web module, an EJB module, an EJB implementation class, or a combination of these elements may be placed in a plurality of subordinate classloaders. Subsequently, one may reload an update to any of these objects without reloading other application modules, thus preserving time, effort, and application stability.
  • the standard classloader organization for an application includes a root classloader for all EJBs in the application.
  • each web application there is a separate classloader that is a child of the application root classloader (sometimes referred to as the EJB classloader). Also, each Java Server Page (JSP) has its own classloader which is a child of its web application's classloader.
  • the standard classloader organization 100 for an application appears as shown in Figure 1 , and includes a root classloader 102, a set of Web app classloaders 104, 106, and classes 108, 110, 112 for the respective Web apps. This is an optimal organization for most users because:
  • a developer (or the system) can reload JSPs individually.
  • Webapps can be reloaded individually.
  • Webapp code can directly reference classes in EJB modules. This allows us to pass EJB parameters by reference rather than by value.
  • a Developer (or the system) can perform namespace separation between web applications.
  • the system doesn't allow namespace separation between EJB modules.
  • Reloadable modules address the problem of being able to reload a module or EJB without reloading all classes in the application, at the expense of being able to directly reference classes in EJB modules.
  • the root classloader and webapp classloader levels are reorganized at the module level, and the individual EJB implementation classes are put in their own classloader.
  • Figure 2 illustrates the resulting classloader architecture
  • a Web app classloader 124 contains all servlet and utility classes for this Web app, while an EJB module classloader 126 contains all classes except the EJB implementation.
  • a third level contains the classes for the JSP's 128, 130, 132. With this architecture, a developer can reload the EJB impl class without affecting the rest of the application. They can also reload an individual EJB module without affecting the rest of the application. These features provides the developer with the ability to organize the first two levels on a per-module basis according to their needs. The third level is done automatically.
  • Application Classloading In a typical application server environment, for example a
  • classloading is centered on the concept of an application.
  • An application is normally packaged in an Enterprise Archive (EAR) file containing application classes. Everything within an EAR file is considered part of the same application. The following may be part of an EAR or can be loaded as standalone applications:
  • EAR Enterprise Archive
  • a Web Application WAR file A Web Application WAR file; and/or,
  • Application WAR file separately, they are considered two applications. If they are deployed together within an EAR file, they are considered a single (i.e. one) application. The developer can deploy components together in an EAR file for them to be considered part of the same application. If the developer needs to use resource adapter-specific classes with Web components (for example, an EJB or Web application), they must bundle these classes in the corresponding component's archive file (for example, the JAR file for EJBs or the WAR file for Web applications).
  • Web components for example, an EJB or Web application
  • Every application receives its own classloader hierarchy.
  • the parent of this hierarchy is the system classpath classloader. This isolates applications so that application A cannot see the classloaders or classes of application B. In classloaders, no sibling or friend concepts exist. Application code only has visibility to classes loaded by the classloader associated with the application (or component), and classes that are loaded by classloaders that are ancestors of the application (or component) classloader. This allows a server such as the WebLogic Server to host multiple isolated applications within the same JVM.
  • WebLogic Server automatically creates a hierarchy of classloaders when an application is deployed.
  • the root classloader in this hierarchy loads any EJB JAR files in the application.
  • a child classloader is created for each Web Application WAR file.
  • the application classloader architecture allows JavaServer Page (JSP) files and servlets to see the EJB interfaces in their parent classloader. This architecture also allows Web Applications to be redeployed without redeploying the EJB tier. In practice, it is more common to change JSP files and servlets than to change the EJB tier.
  • Figure 3 illustrates this WebLogic Server application classloading concept. If the application includes servlets and JSPs that use EJBs, the developer should:
  • the server 144 (in this instance the WebLogic Server) creates sibling classloaders 146, 148 for them. This means that they must include the EJB home and remote interfaces in the WAR file, and the server must use the RMI stub and skeleton classes for EJB calls, just as it does when EJB clients and implementation classes are in different JVMs.
  • the Web application classloader 152, 154 contains all classes for the Web application except for the JSP class.
  • the JSP class 156, 158, 160 obtains its own classloader, which is a child of the Web application classloader. This allows JSPs to be individually reloaded.
  • a developer can create custom classloader hierarchies for an application, which allows for better control over class visibility and reloadability. They achieve this by defining a classloader-structure element in the servers control file or deployment descriptor file (which for example in WebLogic is the weblogic-application.xml file).
  • FIG. 4 illustrates how classloaders are organized by default for applications in a WebLogic implementation.
  • An application level classloader exists where all EJB classes are loaded.
  • JSP classloaders are not shown in Figure 4.
  • This hierarchy is optimal for most applications, because it allows call-by-reference semantics when the developer invokes on EJBs. It also allows Web modules to be independently reloaded without affecting other modules. Further, it allows code running in one of the Web modules to load classes from any of the EJB modules. This is convenient, as it can prevent a Web module from including the interfaces for EJBs that it uses.
  • the ability to create custom module classloaders provides a mechanism to declare alternate classloader organizations that allow the following:
  • the developer can declare the classloader hierarchy in the application deployment descriptor file, for example in a WebLogic environment the weblogic-application.xml file.
  • the document type definition (DTD) for this declaration is as follows:
  • the top-level element in weblogic-application.xml includes an optional classloader-structure element. If the developer does not specify this element, then the standard classloader is used. Also, if the developer does not include a particular module in the definition, it is assigned a classloader, as in the standard hierarchy, i.e., EJB modules are associated with the application Root classloader and Web Modules havetheirown classloaders.
  • the classloader-structure element allows for the nesting of classloader-structure stanzas, so that the developer can describe an arbitrary hierarchy of classloaders. The outermost entry indicates the application classloader. For any modules not listed, the standard hierarchy is assumed.
  • JSP classloaders are not included in this definition scheme. JSPs are always loaded into a classloader that is a child of the classloader associated with the Web module to which it belongs.
  • the following is an example of what a classloader declaration may look like. It will be evident that this example is given for purposes of illustration, and is not intended to limit the scope of the invention in any way. Other examples may be evident to one skilled in the art: ⁇ classloader-structure> ⁇ module-ref>
  • the organization of the nesting in the above classloader declaration indicates the classloader hierarchy.
  • the above stanza can be used to produce a hierarchy such as that illustrated in Figure 5.
  • the modules or individual class files, identified by "module-uri" tags are then retrieved from a storage medium, usually attached to or part of the application server, but in some instance attached to or part of the client environment directly, and loaded into the JVM in the order and according to the relationship hierarchy specified.
  • the application server may also compare the content of a module with the content of previously loaded modules prior to its introduction to the application container in order to prevent the introduction of duplicate modules. If the deployment descriptor or control file specifies that duplicate module or duplicate classes are to be loaded, the application server may perform an event-handling task such as returning a message to the output device or terminating the load altogether.
  • Figure 5 illustrates a search order that can be used for locating classes not found within the same classloader as the calling module in Java applications.
  • the search proceeds up to a higher level of the tree, but is limited to only those classloaders which are a direct "ancestor" of the calling classloader.
  • a class or module located in a "sibling" classloader to the classloader containing the calling class or module will not be located.
  • an EJB module or implementation class 188,190 might require the use of a method located in a web module in a higher tier 182.
  • the classes and modules co-located in the calling classloader can be searched first.
  • the search may proceed to the parent classloader 186 of the classloader which contains the calling class.
  • Each component located in the parent classloader may be searched and, if the method is not found, the search continues further up the hierarchy to the next ancestor classloader 182.
  • the calling module can proceed to create an instantiation of the necessary object(s) for execution.
  • a component 188, 190 required the use of a method located in a sibling classloader 184, the limitations of the traditional search method would require the use of Remote Method Invocation (RMI) in orderto execute the desired method.
  • RMI Remote Method Invocation
  • FIG. 6 illustrates the method used in one embodiment of the invention by the application server to construct the application container.
  • An initial step 200 which can be performed at any time, is to allow the software developer to the edit the application configuration file, which will then determine the hierarchy of modules to be loaded.
  • the application server initially receives a request for loading application components, usually from a client machine although applications may be executed on the same machine on which the application server itself resides.
  • the application server parses the configuration or control file (in one embodiment the application deployment descriptor file, for example in a WebLogic environment the weblogic-application.xml file) which contains the classloader hierarchy.
  • the classes, modules, and other application components specified within the control file are recognized by the application server.
  • the application server proceeds to retrieve the specified application components from a computer readable medium (memory, disk, or other storage) in a manner consistent with the tag layout (i.e. the hierarchy) in the control file.
  • the application server then constructs the application container with the application components in the order in which they were retrieved, resulting in a hierarchical classloader structure in the newly constructed application.
  • Embodiments of the invention may also be used to provide individual EJB classloaders for implementation classes.
  • the server for example WebLogic Server
  • the server allows the developer or the system to reload individual EJB modules without forcing other modules to be reloaded at the same time and having to redeploy the entire EJB module. Since EJB classes are invoked through an interface, it is possible to load individual EJB implementation classes in their own classloader. In this manner, these classes can be reloaded individually without having to redeploy the entire EJB module.
  • Figure 7 shows a diagram of what the classloader hierarchy for a single EJB module looks like.
  • the module 222 contains two EJBs ("Foo" 224 and "Bar” 226 in this example). This represents a sub-tree of the general application hierarchy described in the previous section.
  • the developer can use the following command line to redeploy myejb/foo. class:
  • the developer can then provide a list of files relative to the root of the exploded application that they want to update. This might be the path to a specific element (as above), or a module, or any set of elements and modules. For example, the developer can use the following command to redeploy anotherejb:
  • Java weblogic.Deployer -adminurl uri -user user -password password -name myapp -redeploy mywar myejb/foo. class anotherejb [0050] Given a set of files to be updated, the system tries to figure out the minimum set of things it needs to redeploy. Redeploying only an EJB impl class causes only that class to be redeployed. If the developer specifies the whole EJB (in the above example, anotherejb) or if they change and update the EJB home interface, the entire EJB module must be redeployed. Depending on the classloader hierarchy, this may lead to other modules being redeployed. Specifically, if other modules share the EJB classloader or are loaded into a classloader that is a child to the EJB's classloader, (as in our standard classloader module) then those modules are also reloaded.
  • FIG. 8 illustrates the method used in accordance with an embodiment of the invention to allow reloading of EJB implementations.
  • the system allows the developer to specify EJB's and/or classes that comprise an EJB module hierarchy. This is performed by creating and storing the hierarchy of reloaders in an appropriate configuration file, as described above.
  • the system later receives a request or instruction to redeploy a particular class or module, for example an EJB.
  • the system parses the classloader hierarchy to determine which modules or classes should be redeployed to satisfy the request.
  • the necessary modules, including EJB's and/or classes are redeployed as specified by the classloader hierarchy.
  • the present invention may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings of the present disclosure. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.
  • the present invention includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention.
  • the storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

Abstract

L'invention porte sur un système et un procédé permettant de recharger des modules logiciels individuels dans une mémoire sans avoir à recharger en même temps toutes les classes d'applications, résolvant ainsi le problème imposé par la nécessité de recharger toutes les classes d'applications lors de la recharge d'un module. Dans l'une des exécutions, le chargeur de classes racines et le chargeur de classes d'applications web, sont réorganisés et les modules individuels sont placés dans leur propre chargeur de classes. Le développeur peut ainsi définir l'organisation des chargeurs de classes en fonction de ses besoins. Le système peut alors recharger les modules ou les classes sans affecter le reste des applications.
PCT/US2004/004084 2003-02-12 2004-02-12 Systeme et procede d'utilisation de hierarchie de chargeurs de classes pour charger des applications logicielles. WO2004072821A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US44687803P 2003-02-12 2003-02-12
US44683603P 2003-02-12 2003-02-12
US60/446,836 2003-02-12
US60/446,878 2003-02-12

Publications (2)

Publication Number Publication Date
WO2004072821A2 true WO2004072821A2 (fr) 2004-08-26
WO2004072821A3 WO2004072821A3 (fr) 2004-10-28

Family

ID=32872008

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2004/004084 WO2004072821A2 (fr) 2003-02-12 2004-02-12 Systeme et procede d'utilisation de hierarchie de chargeurs de classes pour charger des applications logicielles.

Country Status (1)

Country Link
WO (1) WO2004072821A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114064215A (zh) * 2021-11-25 2022-02-18 中国建设银行股份有限公司 动态部署模块化的方法、设备、装置及计算机程序产品

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020147971A1 (en) * 2001-02-15 2002-10-10 Adams James Andrew Object-oriented class loading system and method
US6470494B1 (en) * 1998-11-30 2002-10-22 International Business Machines Corporation Class loader
US20030177484A1 (en) * 2002-03-15 2003-09-18 Bosschaert Allaert J. D. Firewall class loader
US20040015936A1 (en) * 2001-05-22 2004-01-22 Sun Microsystems, Inc. Dynamic class reloading mechanism
US20040019897A1 (en) * 2002-07-25 2004-01-29 Sun Microsystems, Inc. Method, system, and program for processing objects in a distributed computing environment
US20040143826A1 (en) * 2003-01-16 2004-07-22 International Business Machines Corporation Externalized classloader information for application servers

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6470494B1 (en) * 1998-11-30 2002-10-22 International Business Machines Corporation Class loader
US20020147971A1 (en) * 2001-02-15 2002-10-10 Adams James Andrew Object-oriented class loading system and method
US20040015936A1 (en) * 2001-05-22 2004-01-22 Sun Microsystems, Inc. Dynamic class reloading mechanism
US20030177484A1 (en) * 2002-03-15 2003-09-18 Bosschaert Allaert J. D. Firewall class loader
US20040019897A1 (en) * 2002-07-25 2004-01-29 Sun Microsystems, Inc. Method, system, and program for processing objects in a distributed computing environment
US20040143826A1 (en) * 2003-01-16 2004-07-22 International Business Machines Corporation Externalized classloader information for application servers

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
GROSSO W.: 'Java RMI, chapter 19', October 2001, O'REILLY AND ASSOCIATES, ISBN 1-56592-452-2 *
LIANG S. ET AL: 'Dynamic class loading in the java virtual machine' ACM vol. 33, no. 10, 1998, pages 36 - 44, XP000831202 *
SING I. ET AL: 'Designing Enterprise Applications, with the J2EE Platform, Second Edition' SUN MICROSYSTEMS 2002, XP002275385 *
'Writing Web Application Deployment Descriptors' BEA, [Online] 2001, XP002977760 Retrieved from the Internet: <URL:http://web.archive.org/web/20010724132 221/http://e-docs.bea.com/wls/docs61/webapp /webappdeployment.html> *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114064215A (zh) * 2021-11-25 2022-02-18 中国建设银行股份有限公司 动态部署模块化的方法、设备、装置及计算机程序产品

Also Published As

Publication number Publication date
WO2004072821A3 (fr) 2004-10-28

Similar Documents

Publication Publication Date Title
US7665080B2 (en) System and method for using a classloader hierarchy to load software applications
US20040255294A1 (en) System and method for hierarchical loading of EJB implementations
US11853774B2 (en) Dynamically loaded plugin architecture
US6738965B1 (en) Trace information in a virtual machine
US7451433B2 (en) System and method for descriptor classes
US8397227B2 (en) Automatic deployment of Java classes using byte code instrumentation
US6470494B1 (en) Class loader
US6871345B1 (en) Self managing software agents with introspection
US7263699B2 (en) Preparation of a software configuration using an XML type programming language
US7627865B2 (en) Method and apparatus for accessing instrumentation data from within a managed code environment
US8997089B2 (en) Computer system and a method of deploying an application in a computer system
US8359590B2 (en) Computer system and a method of deploying an application in a computer system
US5640562A (en) Layering hardware support code on top of an existing operating system
US9569181B2 (en) System and method for supporting an object oriented scripting tool
US20040268301A1 (en) Adding new compiler methods to an integrated development environment
US6633892B1 (en) Archiving tool
US8276125B2 (en) Automatic discovery of the java classloader delegation hierarchy
US8196128B2 (en) System and method for providing a filtering classloader in a computer environment
US20020065943A1 (en) Method and apparatus for automated native code isolation
Corwin et al. MJ: a rational module system for Java and its applications
Halloway Component development for the Java platform
Turner et al. Creating XPCOM Components
WO2004072821A2 (fr) Systeme et procede d&#39;utilisation de hierarchie de chargeurs de classes pour charger des applications logicielles.
Brown et al. Library interface versioning in solaris and linux
WO2003036473A1 (fr) Isolation de langage natif dans une machine virtuelle java multitaches

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase