Mailing-List: contact commits-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Date: Sat, 5 Dec 2015 11:06:11 +0000 (UTC)
From: "Peter Firmstone (JIRA)" <jira@apache.org>
To: commits@river.apache.org
Message-ID: <JIRA.12364215.1173175438000.279647.1449313571068@Atlassian.JIRA>
In-Reply-To: <JIRA.12364215.1173175438000@Atlassian.JIRA>
References: <JIRA.12364215.1173175438000@Atlassian.JIRA>
 <JIRA.12364215.1173175438737@arcas>
Subject: [jira] [Commented] (RIVER-14) Aggregate(Server)Endpoint must become
 standardized (part of the Platform)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/RIVER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15043243#comment-15043243 ] 

Peter Firmstone commented on RIVER-14:
--------------------------------------

The project has been removed from java.net any chance Bob can donate the code?

> Aggregate(Server)Endpoint must become standardized (part of the Platform)
> -------------------------------------------------------------------------
>
>                 Key: RIVER-14
>                 URL: https://issues.apache.org/jira/browse/RIVER-14
>             Project: River
>          Issue Type: Improvement
>          Components: net_jini_jeri
>    Affects Versions: jtsk_2.1
>            Reporter: Mark Brouwer
>
> An aggregate endpoint for Jini ERI stack as is available through [Bob Scheifler's hacks|https://user-rscheifler.dev.java.net] is important in an environment where you want to export your service allowing for both Kerberos and TLS based security, for more context information I refer to the  [discussion|https://user-rscheifler.dev.java.net/servlets/ReadMsg?list=users&msgNo=3] at Bob's project.
> Bob's implementation *as is* is pretty uninteresting at the moment as it doesn't come with an accompanying trust verifier. The use case in the discussion also demonstrates that there is no proper way to get the trust verifier to the client side in a way that is likely going to succeed (assuming security to be important). To me this implies a trust verifier for an aggregate endpoint must be locally available, hence my reference to "part of the Platform" in the summary.
> Although I could incorporate such a trust verifier as part of my own Platform definition this is not going to help interoperability between client and servers in a mixed environment rendering it pretty useless.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)