...
Normally when loading a class the parents are searched first. By including <inverse-classloading/> the classloader is configured to search itself first, then the parents. This feature is probably most familiar in web app classloaders but can be configured on any geronimo classloader.
This technique should be used with caution because it affects all classes and can cause conflicts when objects constructed in your module are passed to a parent for processing. It can be a valuable tool for problem determination and testing, but should be avoided for production systems. In production systems, use the <hidden-classes> element instead and specify only those classes that can be used without conflict.
non-overridable-classes.
If you have configured inverse-classloading, you can override that for specific classes or packages by including filters for those classes you want to be loaded from parent classloaders even if they are present in the current classloader.
This is important when you want your module to share a common instance of a framework library with other modules.
hidden-classes
Including a filter in a hidden-classes element prevents matching classes from being loaded from any parent classloader. This is used when the current module depends on a different version or when the class represents a framework that must be initialized independently from the same framework used by the parent.
This feature is a bit odd. In addition, all child classloaders will not be able to load the class from any parent.
...