I think switching to a different codebase provisioning method is out-of-scope for this specification.
Greg Trasuk On Feb 25, 2014, at 4:04 AM, Peter <j...@zeus.net.au> wrote: > 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) >>>>> >>>> >> >
