----- Original message ----- > 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. >
I'm not doing a good job explaining, see section "4.1 Type Conflicts" in this paper: http://www.sorcersoft.org/resources/jini/smli_tr-2006-149.pdf Then consider what happens when common classes are not available on the class path at runtime. Is my understanding correct; Maven is capable of resolving service api dependencies into a common parent ClassLoader? > > > > 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. > Ok, sorry, wrong assumption, can you explain a little more about how you're using Maven with Rio? Regards, Peter. > > > > > 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) > > >
