From jboss-remoting-commits at lists.jboss.org Tue Dec 30 02:11:19 2008 Content-Type: multipart/mixed; boundary="===============7410699943065074947==" MIME-Version: 1.0 From: jboss-remoting-commits at lists.jboss.org To: jboss-remoting-commits at lists.jboss.org Subject: [jboss-remoting-commits] JBoss Remoting SVN: r4778 - remoting2/branches/2.2/docs/guide/en. Date: Tue, 30 Dec 2008 02:11:16 -0500 Message-ID: --===============7410699943065074947== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Author: ron.sigal(a)jboss.com Date: 2008-12-30 02:11:16 -0500 (Tue, 30 Dec 2008) New Revision: 4778 Added: remoting2/branches/2.2/docs/guide/en/chap-classloaders.xml Modified: remoting2/branches/2.2/docs/guide/en/master.xml Log: JBREM-1041, JBREM-1042: Added section on remote classloading facility. Added: remoting2/branches/2.2/docs/guide/en/chap-classloaders.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- remoting2/branches/2.2/docs/guide/en/chap-classloaders.xml = (rev 0) +++ remoting2/branches/2.2/docs/guide/en/chap-classloaders.xml 2008-12-30 0= 7:11:16 UTC (rev 4778) @@ -0,0 +1,174 @@ + + + Remote classloading facility + + When a Remoting unmarshaller reads a serialized request or respons= e from + the network, it needs to have access to the classes of the objects conta= ined + in the serialized object. Frequently, these will be a simple combination= of + Remoting and Java objects. For example, if an application returns a + java.lang.String, it will be wrapped in an + org.jboss.remoting.InvocationResponse, and both c= lasses + will be known to the unmarshaller. But what if an application returns an + unknown implementation of a known interface? Remoting has a remote + classloading facility to support the latter scenario. + = +
+ Classloading in client invokers + + An instance of + org.jboss.remoting.marshal.serializable.SerializableUnMarsh= aller, + which is the default unmarshaller, or parent of the default unmarshall= er, + for the socket, bisocket, and http transports (marshalling and unmarsh= alling + in the rmi transport is handled by the RMI runtime), will look for cla= sses + in the following order: + = + + + + try system classloader, which loads from locations specifi= ed in the classpath; + + = + + try the Remoting classloader, that is, the classloader that + loaded the Remoting classes (which, depending on the context, ma= y or may not be the system classloader); + + = + + try to load from Remoting's remote classloading facility;<= /para> + + = + + try the current thread's context classloader. + + + = + The current thread's context classloader can be moved to the fro= nt of + the list to enable the alternative behavior: + + + = + + try the current thread's context classloader; + + + + try system classloader, which loads from locations specifi= ed in the classpath; + + = + + try the Remoting classloader, that is, the classloader that + loaded the Remoting classes (which, depending on the context, ma= y or may not be the system classloader); + + = + + try to load from Remoting's remote classloading facility.<= /para> + + + = + 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 for m= ore 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 a= ction + to the contrary, is for a thread's context classloader to be set to th= e 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 t= he + thread context classloader to the EAR classloader whenever it passes c= ontrol + 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 t= he way, + the implication that this discussion about classloading in client invo= kers + applies not only to clients in the ordinary client server sense, but a= lso to + clients running inside the server. +
+ = +
+ Server side support for remote classloading + = + Remoting implements an optional remote classloading facility that + makes it possible for a client invoker unmarshaller to request copies = of + classes that it encounters during the deserialization process. This fa= cility + is provided by a special + org.jboss.remoting.transport.Connector that run= s an + org.jboss.remoting.ServerInvocationHandler desi= gned + to locate and return requested classes. This facility is enabled by + configuring a Connector with the parameter + org.jboss.remoting.InvokerLocator.LOADER_PORT (actual val= ue + "loaderport") set to an available port number. (See for more on configuration options.= ) Using + the "loaderport" parameter will result in the creation of a second + Connector which responds to requests to download + classes. + = + Prior to Remoting release 2.2.2.SP8, the classloading search + implemented by the classloading + SerrverInvocationHandler was the following: + + + + try system classloader, which loads from locations specifie= d 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). + + + = + This original behavior is too restrictive in the context of the r= ich + classloading options of the JBoss Application Server. As of release + 2.2.2.SP8 (with corrections in release 2.2.2.SP11), + it is possible to configure the classloading facility with a list + of org.jboss.mx.loading.HeirarchicalLoaderRepository3 = + class repositories used in the JBoss Application Server. (For more inf= ormation about class repositories and scoped classloading, see Section 3.2.= 2.4. "Inside the JBoss Class Loading Architecture" of the Application Serve= r Guide at + http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/= Server_Configuration_Guide/4/html/index.html.) + = + For example, to allow an EJB3 client to get scoped classes in an = EAR where the jboss-app.xml file is + + + <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.4//EN" = "http://www.jboss.org/j2ee/dtd/jboss-app_4_0.dtd"> + <jboss-app> + <loader-repository>jboss.remoting:loader=3Dtitan.ear</load= er-repository> + </jboss-app> + + = + the EJB3 Connector should look something like the following, wher= e the new "repositories" attribute is used: + + + <mbean code=3D"org.jboss.remoting.transport.Connector" + name=3D"jboss.remoting:type=3DConnector,name=3DDefaultEjb3Connec= tor,handler=3Dejb3"> + <depends>jboss.aop:service=3DAspectDeployer</depends> + <attribute name=3D"Configuration"> + <config> + <invoker transport=3D"socket"> + <attribute name=3D"serverBindAddress">${jboss.bind.ad= dress}</attribute> + <attribute name=3D"serverBindPort">3873</attribute= > + <attribute name=3D"loaderport" isParam=3D"true">3883&= lt;/attribute> + </invoker> + = + <repositories> + <repository>jboss.remoting:loader=3Dtitan.ear</rep= ository> + </repositories> + = + <handlers> + <handler subsystem=3D"AOP">org.jboss.aspects.remoting= .AOPRemotingInvocationHandler</handler> + </handlers> + </config> + </attribute> + </mbean> + + = + That is, the classloader Connector is informed about the Heirarch= icalLoaderRepository3 with JMX ObjectName "jboss.remoting:loader=3Dtitan.ea= r". + = +
+ Modified: remoting2/branches/2.2/docs/guide/en/master.xml =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- remoting2/branches/2.2/docs/guide/en/master.xml 2008-12-30 05:15:07 UTC= (rev 4777) +++ remoting2/branches/2.2/docs/guide/en/master.xml 2008-12-30 07:11:16 UTC= (rev 4778) @@ -7,6 +7,7 @@ + @@ -50,6 +51,8 @@ &chap5; = &chap6; + = + &chap-classloading; = &chap7; = --===============7410699943065074947==--