So Aether standardises obtaining codebases from repository's, and there is no dependency on Maven. It also appears to solve some big security issues.
So this begs the question, shouldn't River be adopting this approach? Is it possible to use a repository, in place of the old http codebase server for the new River single archive container standard? Regards, Peter. ----- Original message ----- > > On Feb 22, 2014, at 1205AM, Peter <j...@zeus.net.au> wrote: > > > > > > 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? > > > > I'm not using Maven per se, I am using Aether > (https://eclipse.org/aether/). There are 2 cases here: > > 1. When a Cybernode is told to instantiate a service, and that service's > classpath is an artifact URL > (artifact:groupId/artifactId/version[/type[/classifier]][;repository[@repositoryId]]), > the artifact is resolved (direct and transitive dependencies) to local > jars (jars are downloaded as needed). This forms that search path for > the classloader created to load the service's implementation class. > > 2. When a service's codebase annotation is an artifact URL, an > implementation of a RMIClassLoaderSpi is used to resolve (along with > it's dependencies and transitive dependencies) the artifact, and install > jars locally. This step is neat, because you can have secure > repositories that require authentication before you can download jars > (the configuration for these sorts of things are in ~/.m2/settings.xml). > All of this happens for downloading, and especially before class loaders > are created and proxy classes loaded. The installed artifact location(s) > are then passed to the default RMIClassLoader provider instance (as file > based URLs), where a class loader is created. > > I think this is a win from multiple points of view: > > - From a performance point of view, instead of accessing classes > remotely (using http(s)), you load them from the file system. > Additionally, if you buy off on version management conventions (where > versions are immutable), once you have downloaded jars, you never have > to download them again. So you pay the price once, not every time you > have to load a service's codebase. > > - You get rid of the lost codebase issue. Once the jars are installed > locally, you have them even if the repository goes down. > > - We trust local code correct? If you can verify the authenticity of the > jars before you download them, verify that the download has not been > tampered with, how far does that go to address trust issues? > > > HTH > > Dennis > > > > > 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) > > > > > > > >
