To minimise the chances of duplicate class loading of service api and avoid implementation class collisions.
This maximises compatibility among proxy's and services common service api classes. Granted, there will be cases where clients don't have service api loaded for particular services, in these cases the downloaded service api classes will reside in the same child ClassLoader as the proxy. This isn't a problem in the majority of cases, but for a smart proxy that uses other services, it could be problematic. Codebase provisioning has an advantage over downloaded code, because such a system can ensure all service api is visible to all services and proxy's, even dynamically after deployment. Maven or OSGi can provision for maximum compatibility among services and proxy's. But because these systems also can use non hirarchical relationships among ClassLoaders, they can experience class loading deadlock, when complex ClassLoader relationships are employed, which parallel class loading in Java 7 tries to address. Unfortunately parallel class loading is a naive attempt to solve this problem, causing a memory consumption explosion with a map based locking system, hopefully a non blocking concurrent class loading system will be implemented in Java 9 to fix class loading deadlock, once and for all. Thankfully class loading relationships among service api, services and proxy's are simple, a hierarchical parent child relationship suffices. Only complex class relationships cause class loading deadlock. Regards, Peter. ----- Original message ----- > > [ > https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908727#comment-13908727 > ] > > Dennis Reedy commented on RIVER-435: > ------------------------------------ > > I'm not sure what the real consequences are if a classloader that loads > service implementation classes and then is a parent to a classloader > then then is used to load either a discovered service (or receives a > remote object as a parameter) is. > > There will be another classloader created by underlying RMI > infrastructure to load the class (since the service classloader) will > not have the other service's proxy classes in it's search path). I may > be missing something, but what are the issues here? > > > Proposed Standard for Single-Archive Service Deployment Packaging > > ----------------------------------------------------------------- > > > > Key: RIVER-435 > > URL: https://issues.apache.org/jira/browse/RIVER-435 > > Project: River > > Issue Type: Improvement > > Components: com_sun_jini_start > > Reporter: Greg Trasuk > > Attachments: SingleArchiveServiceDeployment.docx, > > SingleArchiveServiceDeployment.pdf > > > > > > The attached document proposes the layout and general requirements for > > an archive file to support simplified "drag-and-drop" deployment for > > services that adhere to the Service Starter conventions. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160)
