Use classloading in client invokers
This topic has not yet been written. The content below is from the topic description.
An instance of org.jboss.remoting.marshal.serializable.SerializableUnMarshaller, which is the default unmarshaller, or parent of the default unmarshaller, for the socket, bisocket, and http transports (marshalling and unmarshalling in the rmi transport is handled by the RMI runtime), will look for classes in the following order: try system classloader, which loads from locations specified in the classpath; try the Remoting classloader, that is, the classloader that loaded the Remoting classes (which, depending on the context, may or may not be the system classloader); try to load from Remoting's remote classloading facility; try the current thread's context classloader. The current thread's context classloader can be moved to the front of the list to enable the alternative behavior: try the current thread's context classloader; try system classloader, which loads from locations specified in the classpath; try the Remoting classloader, that is, the classloader that loaded the Remoting classes (which, depending on the context, may or may not be the system classloader); try to load from Remoting's remote classloading facility. This alternative behavior may be enabled either by setting the org.jboss.remoting.Remoting.CLASSLOADING_PARENT_FIRST_DELEGATION parameter (actual value "classloadingParentFirstDelegation") to "false" in the InvokerLocator or in the client invoker's configuration map (see Configuration for more on configuration options) or by setting the system property Remoting.CLASSLOADING_PARENT_FIRST_DELEGATION_PROP (actual value "org.jboss.remoting.classloadingParentFirstDelegation") to "false". Note that the default behavior, in the absence of any explicit action to the contrary, is for a thread's context classloader to be set to the same classloader that loaded the application. However, somewhere outside of Remoting, the context classloader may be set otherwise. For example, a Remoting client invoker might be running inside an EJB3 container that maintains a classloader associated with the EJB3's EAR file and sets the thread context classloader to the EAR classloader whenever it passes control into code supplied in the EAR. This situation would arise when one EJB3 calls another EJB3, where the invocation would ultimately be made by a Remoting client invoker. Note, by the way, the implication that this discussion about classloading in client invokers applies not only to clients in the ordinary client server sense, but also to clients running inside the server.