river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Tue, 25 Feb 2014 14:54:37 GMT

Sent from my iPhone

> On Feb 25, 2014, at 4:04 AM, Peter <jini@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?

In order to do something like this you need to deploy artifacts. Once artifacts are deployed
in to a Maven repository, they are typically served up by an http server.

As this relates to the SAR, my question is do we allow artifact strings under the lib-dl (or
api proxy directories) allowing a services code base to have an artifact URL, or must the
code base be served up using traditional approaches?

I think creating a maven plugin to create the SAR would be trivial, as long as we figure out
what goes in the SAR



> Regards,
> Peter.
> ----- Original message -----
>>> On Feb 22, 2014, at 1205AM, Peter <jini@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)

View raw message