[
https://issues.apache.org/jira/browse/RIVER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Firmstone closed RIVER-14.
--------------------------------
Resolution: Won't Do
This is an old issue, the example is no longer available and wasn't been
donated. This issue, while an interesting feature, hasn't had any up votes.
> 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
> Priority: Major
>
> 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
(v7.6.14#76016)
