On 25/01/2013 8:25 PM, Dan Creswell wrote:
On 25 January 2013 05:47, Peter<j...@zeus.net.au> wrote:
Perhaps it might be time to make JERI a separate release.
+1
I'm all for breaking the codebase down into recognisable/manageable
components for our audience/us. Easier to get to grips with...
JERI method constraints allow authentication to occur prior to code download
and object deserialising.
It Jini's pre JERI implementation that prevents it. Only secure discovery
takes advantage of it. With recent Java security scares, JERI offers an
opportunity to avoid those issues. You can't escape the sandbox if you can't
authenticate to even access it.
Take JERI, make it modern and concurrent, release that separately.
Don't feel we should let the focus on concurrent/modern stop us from
getting something out the door. It'll be an organic process so....
If someone wants to move the current trunk into the development branch
and go back to a stable version, we could prepare that for release.
While it's likely the issues with trunk are actually in the qa suite,
until I finish refactoring the qa suite, we can't be sure.
Jini is restricted to Sun's JVM because of all the legacy cruft no one want's
to let go of. Why should JERI suffer the same fate?
Mmmm, what legacy cruft are you referring too? Not something I'd
considered so interested...
There are parts of Jini that depend on proprietary sun jvm namespace,
preventing it from compiling on other jvm's:
Compiling 863 source files to
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\build\classes
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:31:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
import sun.rmi.server.UnicastServerRef;
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:32:
warning: sun.rmi.transport.LiveRef is Sun proprietary API and may be
removed in a future release
import sun.rmi.transport.LiveRef;
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:115:
warning: sun.rmi.transport.LiveRef is Sun proprietary API and may be
removed in a future release
UnicastServerRef getServerRef(LiveRef lref) {
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:115:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
UnicastServerRef getServerRef(LiveRef lref) {
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:28:
warning: sun.rmi.server.MarshalInputStream is Sun proprietary API and
may be removed in a future release
import sun.rmi.server.MarshalInputStream;
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:29:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
import sun.rmi.server.UnicastServerRef;
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:30:
warning: sun.rmi.transport.LiveRef is Sun proprietary API and may be
removed in a future release
import sun.rmi.transport.LiveRef;
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:61:
warning: sun.rmi.transport.LiveRef is Sun proprietary API and may be
removed in a future release
UnicastServerRef getServerRef(LiveRef lref) {
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:61:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
UnicastServerRef getServerRef(LiveRef lref) {
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:69:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
static class BootstrapServerRef extends UnicastServerRef {
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:87:
warning: sun.rmi.transport.LiveRef is Sun proprietary API and may be
removed in a future release
public BootstrapServerRef(LiveRef lref) {
^
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:63:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
exportMethod = UnicastServerRef.class.getMethod("exportObject",
^
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:93:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
UnicastServerRef uref = getServerRef(new LiveRef(new ObjID(id), port));
^
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:93:
warning: sun.rmi.transport.LiveRef is Sun proprietary API and may be
removed in a future release
UnicastServerRef uref = getServerRef(new LiveRef(new ObjID(id), port));
^
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\SunJrmpExporter.java:116:
warning: sun.rmi.server.UnicastServerRef is Sun proprietary API and may
be removed in a future release
return new UnicastServerRef(lref);
^
C:\Users\peter\Documents\NetBeansProjects\peterConcurrentPolicy\src\com\sun\jini\phoenix\RegistrySunExporter.java:76:
warning: sun.rmi.server.MarshalInputStream is Sun proprietary API and
may be removed in a future release
MarshalInputStream.class.getDeclaredMethod(
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
16 warnings
If we can slim down and make the codebase more managable, maintainable
and approachable we might gather some pace, right now there's just too
much for new people to digest and too much for a small team to maintain
effectively.
The ServiceRegistrar interface was one of the earliest service
interfaces designed, security wasn't a huge consideration, it was
probably well designed in the 90's, but quite honestly, we should
replace it, but doing so adds to the conceptual size of the codebase,
the more we cling onto backward compatibility, the more cruft we
accumulate, users have to try and work out which version to use, classes
like LookupLocator too have this issue. Some code I call legacy code
because it's difficult to maintain, due to insufficient synchronization
or big objects with lots of fields that are hard to reason about. Some
code is clean and simple, I like that code.
But really shouldn't classes like LookupLocator be retired in favour of
something new? ServiceLocator? Something service agnostic? The client
know's the type of service it's looking for, shouldn't the client be
responsible for checking the type? Yes I know LookupLocator is intended
to be a discovery mechanism, but when you get to the crux of the matter,
a Lookup service is just a service, so why shouldn't it be possible to
locate other services as well?
Also ServiceLocator should only be a value class, similar to URI or
String. ServiceLocator could be passed to another object that checks
method constraints and has SPI interfaces for various methods of
creating connections over JERI endpoints, authenticating (if required)
before instantiating a service object. ServiceLocator could also
contain a list of Interfaces of implemented ServiceAPI.
ServiceRegistrar could return a ServiceLocator along with a list of
Entry objects that are resolvable to local classes. At present we
deserialize services first, then ask questions later, by then it's too
late if the service wasn't trusted, untrusted code has been allowed to
run during unmarshalling. I think we can forget the sandbox, any code
that runs on your jvm can perform privilege escallation, code must be
trusted to run. If you run a server, you can limit the permissions of
the user the server runs under, so even if the code escapes the sandbox
it can't do too much damage, but now I'm starting to head off on a
tangent. There's the simple case of reflective proxy's for services,
really we should have another constraint that ensures the service proxy
is reflective only and is prohibited from initiating code downloads. If
using only reflective proxy's and no downloaded code, it's safe to talk
to strangers, so you could avoid the need for authentication.
If I remember rightly, at some point additional utility classes were
added to Jini to try address some criticisms with ServiceRegistrar,
perhaps it's time to review those criticisms too.
I think using object serial form for Entry comparison was the right
compromise at the server, there's still much to be liked about the
design of Jini.
Many developers also appear to maintain their own custom Jini branch,
with additional features or tweaks.
If others were also interested, I'd consider starting a bottom up
reconstruction of River, breaking compatibility where it makes sense
while keeping it lean. This would probably be infrastructure only, so
only the stuff you need to get started would be included. It would also
be capable of being compiled on any Java SE 6+ compatible jvm.
Before such an undertaking, I'd want to finish qa refactoring and see
another release though.
Just a few thoughts, or a rant.
Cheers,
Peter.
