A DESCRIPTION OF THE REQUEST :
The java.util.prefs.Preferences loads the custom preferences factory using the system class loader only. This is a limiting factor in J2EE application deployment, since all the application code including custom backing storage is bundled inside a J2EE application.
JUSTIFICATION :
1. To follow the standard deployment packaing rules for J2EE (i.e. bundling the utility jars inside the J2EE application)
2. To support multiple backing storage (say, one per application). Some J2EE application servers have only one location to specify extended JVM libraries and this limits the capabilities of custom backing storage since we would have atmost one implementation of the custom back storage.
3. Multiple versions of the same custom backing storage. In a multi-application deployment, each application might use a different version of the same custom backing storage. By eliminating the restriction on custom backing storage load policy (currently limited to system class loader), each application in the cluster can have their own version of custom backing storage for preferences
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Class Name: java.util.prefs.Preferences
factory0 = (PreferencesFactory)
Class.forName(factoryName, false,
ClassLoader.getCallerClassLoader()).newInstance();
ACTUAL -
Class Name: java.util.prefs.Preferences
factory0 = (PreferencesFactory)
Class.forName(factoryName, false,
ClassLoader.getSystemClassLoader()).newInstance();
The java.util.prefs.Preferences loads the custom preferences factory using the system class loader only. This is a limiting factor in J2EE application deployment, since all the application code including custom backing storage is bundled inside a J2EE application.
JUSTIFICATION :
1. To follow the standard deployment packaing rules for J2EE (i.e. bundling the utility jars inside the J2EE application)
2. To support multiple backing storage (say, one per application). Some J2EE application servers have only one location to specify extended JVM libraries and this limits the capabilities of custom backing storage since we would have atmost one implementation of the custom back storage.
3. Multiple versions of the same custom backing storage. In a multi-application deployment, each application might use a different version of the same custom backing storage. By eliminating the restriction on custom backing storage load policy (currently limited to system class loader), each application in the cluster can have their own version of custom backing storage for preferences
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Class Name: java.util.prefs.Preferences
factory0 = (PreferencesFactory)
Class.forName(factoryName, false,
ClassLoader.getCallerClassLoader()).newInstance();
ACTUAL -
Class Name: java.util.prefs.Preferences
factory0 = (PreferencesFactory)
Class.forName(factoryName, false,
ClassLoader.getSystemClassLoader()).newInstance();