-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 or a smart proxy is none of the client’s business, and the client code shouldn’t be coupled to the implementation of the service. - Ideas that go “in a future version of River” ought to be fully fleshed out and discussed before we start implementing them. In particular, this “bootstrap proxy” idea - I don’t intend to delve into it now, but I can’t help but wonder whether it’s better implemented using the existing ProxyPreparer mechanism, or some decoupling between the service item and its claimed interfaces. Not to mention, the need for it hasn’t been established. In any case, we shouldn’t implement things until we’ve talked about them. We’ve agreed to be cautious about changing the public API. Cheers, Greg Trasuk > On Jan 5, 2016, at 1:41 AM, Peter Firmstone <peter.firmst...@zeus.net.au> > wrote: > > 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 which is a reflective proxy or remote proxy stub. > > Often, the former contains the latter, where the former implements service > api, while the latter is used for remote communication with the service's > server. > > In a future version of River, ServiceProxyAccessor could be used by clients > to obtain the service proxy, from a bootstrap proxy, allowing authentication > to occur prior to codebase download and unmarshalling. Think security and > delayed unmarshalling. > > If this was to occur, we'd need to change the package for the > ServiceProxyAccessor interface, to net.jini.export. > > Seeing as we're about to change the package of ServiceProxyAccessor in the > 3.0 release, it would have less impact on downstream code if this change was > only made once. > > If the security and performance improvements were not accepted, (I'm quite > confident that we will agree on a solution once the benefits can be > demonstrated) it still makes sense to move ServiceProxyAccessor to > net.jini.exporter due to their related use and functionality. > > Should I proceed with a vote to move ServiceProxyAccessor to net.jiniexporter > now, prior to release, or should I leave it until River 3.1? > > This wont cause a delay in the release process, but I'm happy to leave it if > anyone is concerned it will. > > Regards, > > Peter. > > Sent from my Samsung device. >
