Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.reedy@gmail.com
 designates 209.85.223.170 as permitted sender)
References: <JIRA.12695948.1392814956957@arcas>
 <JIRA.12695948.1392814956957.83141.1393011680601@arcas>
 <1393023189.3899.5.camel@Nokia-N900>
 <B486F194-12A7-403D-90CE-6FE30CEAE212@gmail.com>
 <4C968F1D-7363-4337-B15C-3C237C5EC95A@gmail.com>
 <1393319080.10590.14.camel@Nokia-N900>
Mime-Version: 1.0 (1.0)
In-Reply-To: <1393319080.10590.14.camel@Nokia-N900>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <40A2DD9B-3351-46CB-AC3E-D5B011AD297D@gmail.com>
Cc: "dev@river.apache.org" <dev@river.apache.org>
From: Dennis Reedy <dennis.reedy@gmail.com>
Subject: Re: [jira] [Commented] (RIVER-435) Proposed Standard for
 Single-Archive Service Deployment Packaging
Date: Tue, 25 Feb 2014 09:54:37 -0500
To: "dev@river.apache.org" <dev@river.apache.org>


Sent from my iPhone

> On Feb 25, 2014, at 4:04 AM, Peter <jini@zeus.net.au> wrote:
>=20
> So Aether standardises obtaining codebases from repository's, and there is=
 no dependency on Maven.  It also appears to solve some big security issues.=

>=20
> So this begs the question, shouldn't River be adopting this approach?
>=20
> Is it possible to use a repository, in place of the old http codebase serv=
er for the new River single archive container standard?

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

As this relates to the SAR, my question is do we allow artifact strings unde=
r the lib-dl (or api proxy directories) allowing a services code base to hav=
e an artifact URL, or must the code base be served up using traditional appr=
oaches?

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

Regards

Dennis


>=20
> Regards,
>=20
> Peter.
>=20
> ----- Original message -----
>>=20
>>> On Feb 22, 2014, at 1205AM, Peter <jini@zeus.net.au> wrote:
>>>=20
>>>>> Maven or OSGi can provision for maximum compatibility among
>>>>> services   and proxy's.
>>>>=20
>>>> 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.
>>>=20
>>> Ok, sorry, wrong assumption, can you explain a little more about how
>>> you're using Maven with Rio?
>>=20
>> I'm not using Maven per se, I am using Aether
>> (https://eclipse.org/aether/). There are 2 cases here:
>>=20
>> 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[@rep=
ositoryId]]),
>> 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.
>>=20
>> 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.
>>=20
>> I think this is a win from multiple points of view:
>>=20
>> - =46rom 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.
>>=20
>> - You get rid of the lost codebase issue. Once the jars are installed
>> locally, you have them even if the repository goes down.
>>=20
>> - 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?
>>=20
>>=20
>> HTH
>>=20
>> Dennis
>>=20
>>>=20
>>> Regards,
>>>=20
>>> Peter.
>>>=20
>>>>=20
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Regards,
>>>>>=20
>>>>> Peter.
>>>>>=20
>>>>> ----- Original message -----
>>>>>>=20
>>>>>> [
>>>>>> https://issues.apache.org/jira/browse/RIVER-435?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D139087=
27#comment-13908727
>>>>>> ]
>>>>>>=20
>>>>>> Dennis Reedy commented on RIVER-435:
>>>>>> ------------------------------------
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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?
>>>>>>=20
>>>>>>> Proposed Standard for Single-Archive Service Deployment
>>>>>>> Packaging
>>>>>>> -----------------------------------------------------------------
>>>>>>>=20
>>>>>>> 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
>>>>>>>=20
>>>>>>>=20
>>>>>>> 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.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> This message was sent by Atlassian JIRA
>>>>>> (v6.1.5#6160)
>=20