Sun Microsystems, Inc.

Oracle America, Inc.

Bjorn Carlson

Milton Soong

Santosh Hasani

System and method for enabling dynamic class reloading in an application server environment. A distinction is made between 'versionable' and 'non-versionable' classes. Versionable classes are classes that should be automatically reloaded when they are modified. The application server(s) may execute a background task that executes periodically to check for modified versionable classes. Users may specify class versionability by specifying a list of explicitly versionable classes, specifying a list of superclasses whose extending classes should be considered to be versionable, and specifying a list of interfaces whose implementing classes should be considered to be versionable. Once the background task discovers a modified versionable class, the background task may cause the class to be reloaded, e.g., by instantiating a new classloader and instructing the new classloader to reload the class. The background task may purge the reloaded class from any caches that the application server maintains.

System and method for enabling dynamic modifed class reloading in an application server environment

Disclosed is a system and method for enabling dynamic class reloading in the application server environment. Users may specify class versionability by specifying a list of explicitly versionable classes; and the application server(s) may execute a background task which operates periodically to check modified versionable classes, and cause the classes to be reloaded. Administrators may specify a set of class files to be treated as a 'bundle'. When the bundle is deployed, a deployer manager may obtain a lock, e.g. a semaphore, referred to as the 'dirtyClassListLock'. Once this lock is obtained, the deployer manager may copy all the class files in the bundle from a deployment environment to their appropriate runtime locations. After the runtime locations have been updated, the deployer manager may release the dirtyClassListLock. According to this method, the background task that checks for and reloads modified classes may also have to obtain the dirtyClassListLock in order to run. Thus, the background task will discover and reload class files in the bundle atomically.

System and method for enabling atomic class loading in an application server environment

System and method for caching JavaServer Page&trade; (JSP) component responses. The JSP components may be components that execute on an application server that supports networked applications, such as web applications or other Internet-based applications. One or more client computers, e.g., web servers, may perform requests referencing the JSP components on the application server. The execution of JSP components may be managed by a JSP engine process running on the application server. When a request referencing a JSP is received from a client computer, the JSP engine may first check a JSP response cache to determine whether a valid JSP response satisfying the request is present. If a matching cached response is found, then the response may be retrieved and immediately streamed back to the client. Otherwise, the referenced JSP may be executed. Each JSP file may comprise various SetCacheCriteria( ) method calls. When executed, the SetCacheCriteria( ) call may cause the output of the JSP to be cached once the JSP execution is complete. Arguments to the SetCacheCriteria( ) call may specify a criteria set that should be associated with the cached JSP response. This criteria set may then be used to match against attributes of future JSP requests, as described above. In particular embodiments, any of various types of cache criteria may be supported.

Growing community of inventors

Mtn. View, CA, United States of America

Bjorn Carlson