Various parties have already pointed out the security concerns with the existing remote classloading system and the need to better integrate with the AS classloader system. There are (at least) three points where security is significant to remote classloading. (1) The loading endpoint needs to be able to control whether or not a given class may be remotely loaded from a given peer, and by whom. This could possibly be implemented as some sort of permission, with parameters to specify what range of classes the permission applies to and what remote services may be loaded from. In addition it might be beneficial to have a global "off switch" as an easy way to secure an endpoint. (2) The loading endpoint needs to be able to assign permissions to the loaded class. This should be doable using the client's security policy mechanism, preferably using some type of codeBase URL that is able to specify the source of the loaded class. (3) The endpoint from which the classes are sent needs to be able to restrict the scope of what classes are made available to the client, so as not to "leak" any potentially sensitive classes. This could possibly function at a module granularity (JAR file) or at a package/class granularity. A quick note - in Remoting 3, classes may conceptually be sent either from client to server (as part of a request) or from server to client (as part of a reply). Here's a couple proposals for how to implement it. (1) A Remote VFS scheme This solution entails creating a VFS plugin that uses Remoting to load resources ("vfsremote:<remoting-service-URI>" perhaps). A Remoting service would be created which exports some subset of one system's VFS. A client would then connect to this service, creating a VFS view of the remote system. Then a classloader which includes a VFSClassLoader referencing this view is created and injected into the Remoting client configuration (specifically, as the classloader used by the ClassResolver of the MarhsallerFactory). This can then be secured by using a VFS codeBase URL (assuming we get that working, which I'm confident is possible, one way or another). Pros: very elegant. Uses all our various cool JBoss doodads together. No enhancements to the Remoting codebase are necessary. No new classloader implementations are needed. Avoids the various issues that have come up with the current implementation. Uses standard security configuration. Possibly has other uses outside of remote classloading. Cons: standalone clients might be very complex, having to include a bunch of our classloading and VFS stuff in order to gain access to the remote classes/jars/etc. We would need to devise a way to simplify client configuration as well - maybe even producing a special API for writing simple clients which preconfigures all this stuff at once. (2) A RemoteClassLoader implementation With this solution, we create a ClassLoader implementation which uses a custom remote classloading service. The server side would wrap one or more ClassLoader instance(s) to which class lookups are delegated. Pros: simpler for clients - they'd just have to create a RemoteClassLoader implementation. Cons: there are a lot of features in classloaders that do not have a clear mapping across a remote channel. Getting resources, packages, and security manager considerations all weigh in to this. I would expect a lot more design bugs with this approach compared to implementation bugs. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183976#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...