Wishlist
(Difference between revisions)
Cschoenfeld (Talk | contribs) (Suggestion about a module classloader) |
Cschoenfeld (Talk | contribs) m (added open question and details about delegation) |
||
| Line 1: | Line 1: | ||
== Custom ClassLoaders for Modules == | == Custom ClassLoaders for Modules == | ||
OpenCms should provide its own ClassLoader for each module. | OpenCms should provide its own ClassLoader for each module. | ||
| − | * The Module ClassLoader is instantiated along with the module and used to load classes, classpath resources | + | * The Module ClassLoader is instantiated along with the module and used to load classes, classpath resources and libraries contained in the module directly from VFS. |
* The classpath of a Module ClassLoader contains | * The classpath of a Module ClassLoader contains | ||
** /system/modules/<modulename>/classes/ | ** /system/modules/<modulename>/classes/ | ||
** /system/modules/<modulename>/lib/*.jar | ** /system/modules/<modulename>/lib/*.jar | ||
| + | * Module dependencies make up a Module ClassLoader hierarchy. If module B depends on module A, the Module ClassLoader of B has the Module ClassLoader of A as a parent, thereby making A's classpath available to B. | ||
| + | * The Module ClassLoader of a module which does not depend on a different module has the standard Webapp ClassLoader as its parent. | ||
| + | * When a class should be loaded, the Module ClassLoader first looks into the module classpath. If it does not find the class there it delegates class loading to its parent. | ||
* Each time OpenCms detects that a file on the Module ClassLoader classpath changes, the Module ClassLoader is thrown away and a new instance is created. | * Each time OpenCms detects that a file on the Module ClassLoader classpath changes, the Module ClassLoader is thrown away and a new instance is created. | ||
| − | |||
Benefits: | Benefits: | ||
| Line 12: | Line 14: | ||
* It is no longer required reload OpenCms for each change to a module classpath file. | * It is no longer required reload OpenCms for each change to a module classpath file. | ||
* Ability to use different and incompatible versions of libraries in different modules. | * Ability to use different and incompatible versions of libraries in different modules. | ||
| + | |||
| + | Open Questions: How would the Module ClassLoader perform JSP loading? | ||
Revision as of 11:30, 17 November 2006
Custom ClassLoaders for Modules
OpenCms should provide its own ClassLoader for each module.
- The Module ClassLoader is instantiated along with the module and used to load classes, classpath resources and libraries contained in the module directly from VFS.
- The classpath of a Module ClassLoader contains
- /system/modules/<modulename>/classes/
- /system/modules/<modulename>/lib/*.jar
- Module dependencies make up a Module ClassLoader hierarchy. If module B depends on module A, the Module ClassLoader of B has the Module ClassLoader of A as a parent, thereby making A's classpath available to B.
- The Module ClassLoader of a module which does not depend on a different module has the standard Webapp ClassLoader as its parent.
- When a class should be loaded, the Module ClassLoader first looks into the module classpath. If it does not find the class there it delegates class loading to its parent.
- Each time OpenCms detects that a file on the Module ClassLoader classpath changes, the Module ClassLoader is thrown away and a new instance is created.
Benefits:
- No need to export files from the VFS to WEB-INF/lib and WEB-INF/classes.
- It is no longer required reload OpenCms for each change to a module classpath file.
- Ability to use different and incompatible versions of libraries in different modules.
Open Questions: How would the Module ClassLoader perform JSP loading?
