5 Replies Latest reply on Feb 12, 2007 9:54 PM by Tom Elrod

    Remote Classloading Service Redesign - JBAS-2075

    Adrian Brock Master

      This thread is for the discussion of issues related to JBAS-2075
      and the redesign/enhancement of the remote classloading service.

        • 1. Re: Remote Classloading Service Redesign - JBAS-2075
          Scott Stark Master

          What is the current remoting class loading support status?

          • 2. Re: Remote Classloading Service Redesign - JBAS-2075
            Tom Elrod Master

            The dynamic, remote classloading is not complete in remoting yet (JBREM-47). However, it is implemented, but just being used specifically for loading marshallers/unmarshallers currently. Would need to open up for all classes.

            As for JBAS-2075:

            1. Provide sensible defaults (no remote classloading by default)

            Easy enough. Currently has to be configured in the Connector configuration as is now.

            2. Individula deployments can choose whether remote classloading is enabled and what would be made available.

            This will be more difficult as remoting does not really know about applications per say. Might could so specifically for subsystem. Might could also add full on configuration for the classloader server part so can specify which classes can be served. However, don't see how any of this can be integrated in application deployment information, if that is what you are sugesting.

            3. Allow "aspects" of the deployment to enchance what can be downloaded.

            Same as above.

            4. Use the spec defined RMIClassloaderSPI.

            not familiar enough with this to comment.

            5. Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that triggers the use of inovkers to do remote classloading.

            This is basically how it works now.

            • 3. Re: Remote Classloading Service Redesign - JBAS-2075
              Scott Stark Master

              We talked in the past that application level classes have to be loaded outside of the base remoting layer using an application class loader. This could be done either by having a class loader that is keyed off of some request context or by delaying the marshalling of the application payload until a point in the dispatch chain where the application class loader is available.

              What is currently done? This is related to the 2, 3 issues.

              • 4. Re: Remote Classloading Service Redesign - JBAS-2075
                Tom Elrod Master

                The UnifiedInvokerProxy sends the MarshalledInvocation as the payload currently (just like in the other protocols). This allows for the delay of the unmarshalling of the MarshalledInvocation payload till it gets to the UnifiedInvoker.

                However, for anything else, would need to do the same (have the user of remoting pass marshalled object) or change remoting to always do this on behalf of the user.

                • 5. Re: Remote Classloading Service Redesign - JBAS-2075
                  Tom Elrod Master

                  Seems to me should be handled at the invoker level (i.e. UnifiedInvoker) and use a service like the org.jboss.web.WebService we currently have. The WebService actually looks fairly good to me to what is needed (i.e. downloading classes). Maybe add another configuration attribute for what type of class files can be downloaded (i.e. "com.acme.domain.*") and should be sufficient?

                  Also, where is the client code for downloading classes from the WebService?