ServiceProxyAccesor is an interface in the start package, a similar interface
called ProxyAccessor exists in the net.jini.export package.
The difference between these two interfaces is the former returns a smart
proxy, which may not be a Remote object, while the latter returns the Remote
proxy
-1
A few reasons;
- ProxyAccessor exists primarily to go along with the activation system, which
is slated to be removed.
- ServiceProxyAccessor goes with the ‘start’ package, that is an implementation
detail that not all containers use
- Whether a service is implemented by a reflective proxy
an it was in 2004, not less.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Greg Trasuk
Sent: 06/01/2016 02:02:50 am
To: dev@river.apache.org
Subject: Re: Release 3.0, package rename and ServiceProxyAccessor
-1
A few reasons;
> On Jan 5, 2016, at 10:51 PM, Peter wrote:
>
>
>
> ProxyPreparer in its current form is broken.
>
> Proxy preparation assumed that both the java sandbox and serialization are
> secure, code is downloaded, static class initialisers and readObject methods
> are executed on untrusted forei
idation matters.
Sent from my Samsung device.
Include original message
Original message
From: Greg Trasuk
Sent: 06/01/2016 04:12:35 pm
To: dev@river.apache.org
Subject: Re: Release 3.0, package rename and ServiceProxyAccessor
> On Jan 5, 2016, at 10:51 PM, Peter wrote:
&g
On 06-01-16 13:38, Peter wrote:
Your security analysis is too narrow, your thinking like a user, not an
attacker.
An attacker is not going to send you a proxy to load into a standalone
Classloader. She has the choice of the entire classpath, not you and not
River, that's right it's the sende
On 06-01-16 18:49, Simon IJskes - QCG wrote:
On 06-01-16 13:38, Peter wrote:
Your security analysis is too narrow, your thinking like a user, not
an attacker.
An attacker is not going to send you a proxy to load into a standalone
Classloader. She has the choice of the entire classpath, not you
