[JBoss-dev] UCL as system classloader under 1.4: is that a problem for you

[Sacha L. <Sac...@co...>]

Hello,

A new property, "java.system.class.loader", can be used under 1.4 to
determine which should be the system classloader: the standard java CL or a
customized CL. As we move forward 1.4, it means that setting the UCL as the
value of this property would allow us to simply the code regarding
setContextClassLoader for example (and other improvments).

But would that be a problem for some of your code? I think about JBossSX for
example (how JAAS security modules get loaded for example)?

Thank you for your feedback. Cheers,


				Sacha

Extract from java.lang.Classloader source:

    /**
     * Returns the system class loader for delegation. This is the default
     * delegation parent for new <code>ClassLoader</code> instances, and
     * is typically the class loader used to start the application.
     * <p>
     * This method is first invoked early in the runtime's startup
     * sequence, at which point it creates the system class loader
     * and sets it as the context class loader of the invoking
     * <tt>Thread</tt>.
     * <p>
     * The default system class loader is an implementation-dependent
     * instance of this class.
     * <p>
     * If the system property <tt>java.system.class.loader</tt> is
     * defined when this method is first invoked then the value of that
     * property is taken to be the name of a class that will be returned as
     * the system class loader. The class is loaded using the default system
     * class loader and must define a public constructor that takes a single
     * parameter of type <tt>ClassLoader</tt> which is used
     * as the delegation parent. An instance is then created using this
     * constructor with the default system class loader as the parameter.
     * The resulting class loader is defined to be the system class loader.
     * <p>
     * If a security manager is present, and the caller's class loader is
     * not null and the caller's class loader is not the same as or an
ancestor of
     * the system class loader, then
     * this method calls the security manager's <code>checkPermission</code>
     * method with a <code>RuntimePermission("getClassLoader")</code>
     * permission to ensure it's ok to access the system class loader.
     * If not, a <code>SecurityException</code> will be thrown.
     *
     * @return the system <code>ClassLoader</code> for delegation, or
     *         <code>null</code> if none
     * @throws SecurityException
     *        if a security manager exists and its
     *        <code>checkPermission</code> method doesn't allow
     *        access to the system class loader.
     * @throws IllegalStateException
     *        if invoked recursively during the construction
     *        of the class loader specified by the
     *        <code>java.system.class.loader</code> property.
     * @throws Error
     *        if the system property <tt>java.system.class.loader</tt>
     *        is defined but the named class could not be loaded, the
     *        provider class does not define the required constructor, or an
     *        exception is thrown by that constructor when it is invoked.
The
     *        underlying cause of the error can be retrieved via the
     *        {@link Throwable#getCause()} method.
     * @see SecurityManager#checkPermission
     * @see java.lang.RuntimePermission
     * @revised 1.4
     */
    public static ClassLoader getSystemClassLoader() {
...