JBossRMIClassLoader (JBoss System API) - JBoss 3.2.7 system API Documentation 英文版文档

Overview

Package

Class

Use

Tree

Deprecated

Index

Help

PREV CLASS NEXT CLASS

FRAMES NO FRAMES

SUMMARY: NESTED | FIELD | CONSTR | METHOD

DETAIL: FIELD | CONSTR | METHOD

org.jboss.system
Class JBossRMIClassLoader

java.lang.Object
  java.rmi.server.RMIClassLoaderSpi
      org.jboss.system.JBossRMIClassLoader

public class JBossRMIClassLoader
extends RMIClassLoaderSpi

An implementation of RMIClassLoaderSpi to workaround the proxy ClassCastException problem in 1.4

THIS IS A HACK!

Sun's implementation uses the caller classloader when unmarshalling proxies. This is effectively jboss.jar since that is where JRMPInvokerProxy lives. On a redeploy the new interfaces are ignored because a proxy is already cached against the classloader.

Another redeployment problem is that the getClassAnnotation(String) will end up using the old deployment class loader and this can result in NPEs do the class loader being destroyed. This class ignores Sun's guess at a suitable classloader and uses the thread context classloader instead.

It has to exist in the system classloader so I have included it in "system" for inclusion in run.jar

Version:: $Revision: 1.1.4.3 $
Author:: Adrian Brock, Scott.Stark@jboss.org

Constructor Summary

JBossRMIClassLoader()
          Required constructor

Method Summary

String getClassAnnotation(Class cl)
          Try to delegate an default to the java.rmi.server.codebase on any failure.

ClassLoader getClassLoader(String codebase)
          Just delegate

Class loadClass(String codebase, String name, ClassLoader ignored)
          Just delegate

Class loadProxyClass(String codebase, String[] interfaces, ClassLoader ignored)
          Ignore the JVM, use the thread context classloader for proxy caching

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail