river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Tue, 25 Feb 2014 13:36:21 GMT

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 <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?
> 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