Hi Peter, I'm not sure we're on the same wavelength here, I've inlined some comments below.
Regards Dennis On Feb 21, 2014, at 553PM, Peter <j...@zeus.net.au> wrote: > To minimise the chances of duplicate class loading of service api and avoid > implementation class collisions. You'll never get duplicate class loading, because of the hierarchical structure of class loaders. > > 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, Clients must have service APIs in their classpath, they would never be able to load a service's interface (to perform a discovery for example) otherwise. > 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. Clients will dynamically load a service's proxy, a service API will always be in the client's classpath. You need to know a-priori the service type you're looking for and intend to use after all. > > 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. Maven does absolutely nothing in this regard, and in the case of OSGi, we are dealing with a completely different class loading animal. Provisioning systems that either use Maven's dependency resolution (Aether) to make resolved artifacts loadable as local jars are a different story. > > 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) >
