Abstract: A method for determining a software configuration in a computer system having a plurality of devices which can communicate with a central server and a one or more shared file systems, the method including the acts of determining, by each of the plurality of devices, which of the one or more shared file systems the corresponding device is mounted to; designating for each of the one or more shared file systems a device which is mounted thereto to perform a scanning operation on the corresponding shared file system, the device being selected from the plurality of devices; scanning, by each designated device, the one or more shared file systems that the corresponding device has been designated to scan so as to identify software products on the corresponding shared file systems that correspond with the catalog information; and receiving, from each designated device, results of the scanning for further processing.

Abstract: A set of plug-in class loaders is provided in the class loader hierarchy. A plug-in class loader is provided for each class loader in the plug-in application's class loader hierarchy. Each plug-in class loader is associated with a single application class loader and is configured such that it delegates to its associated application class loader. All plug-in class loaders are also configured with a class path such that they may load plug-in classes from a directory that is specified within a configuration file. The loading of all plug-in classes is initiated by the application using the plug-in class loaders.

Abstract: A technique is presented for determining the defining ClassLoader class of a Java class as it is being defined within a Java Virtual Machine (JVM) by instrumenting the “java.lang.ClassLoader” class. Within a JVM, all ClassLoader instances call one of the “defineClass” methods of class “java.lang.ClassLoader” in order to pass the raw bytes for loaded a class to the JVM to have it defined as a Java class. Therefore, instrumentation code is inserted into the “defineClass” methods of class “java.lang.ClassLoader”; the instrumentation code stores an identity of the defining ClassLoader prior to the invocation of the class load hook by the JVM, which can use the identity of the defining ClassLoader for various purposes.

Abstract: A technique is presented for instrumenting a Java application in a just-in-time fashion. A software developer obtains Java class files that comprise an application that the software developer desires to instrument. The software developer also obtains code for instrumentation probes; each probe is associated with a location in an application, e.g., a specific method within a specific class. The probes along with the associated locations are registered in a registry, either programmatically or by loading a configuration file. At class load time, an injector determines whether a loaded class has any instrumentation locations as predetermined by information in the registry. If so, the injector inserts hooks in the loaded class. When the hooks are executed, the hooks can manage the execution of the probes, which can be dynamically added or removed from the registry during runtime and/or dynamically enabled or disabled during runtime.