You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Gregg Wonderly <ge...@cox.net> on 2013/01/24 05:39:31 UTC
Dirmi might be something to look at
I didn't know about this project. The more things like this I see, the more it
really seems River is hidden from view, more and more.
http://sourceforge.net/apps/mediawiki/dirmi/index.php?title=Dirmi
Gregg Wonderly
Re: Dirmi might be something to look at
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 27/01/2013 7:57 AM, Tim Blackman wrote:
> On Jan 26, 2013, at 8:26 AM, Peter Firmstone<ji...@zeus.net.au> wrote:
>
>> 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
> The JRMP exporter is just a way to use Exporters with standard RMI rather than JERI. You could convert that into a separate distribution that was specific to the Sun/Oracle JVM. Of course, since the things in question are part of RMI, they are probably part of most Java implementations anyway. Definitely separate from JERI.
>
In this case SunJrmpExporter is unique to Phoenix, the exporter in
net.jini.jrmp.JrmpExporter doesn't utilise private namespace.
SunJrmpExporter allows a known java.rmi.server.ObjID to be used, while
JrmpExporter doesn't.
The question is: "Does Phoenix need to use a Registry exported over
JRMP, for activatable services that use a JRMP exporter?"
>> 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
> Hmm, not as sure about this one.
> Is this exporter needed for Phoenix?
Yes.
If we wanted activation, we'd need to replace the functionality in
java.rmi.registry.LocateRegistry, to allow a Registry to be exported
over JERI endpoints. Registry is a service provided at a known
location, used for bootstrapping.
> Do you view activation as an important part of JERI, or could that be split out as well?
I guess it would depend on the amount of work required, the Activation
interfaces could stay, the implementation, Phoenix, can't without first
replacing functionality in classes that access sun private namespace ,
so it would be provided separately.
Thanks Tim, glad to see you're still monitoring the list ;)
Cheers,
Peter.
Re: Dirmi might be something to look at
Posted by Tim Blackman <ti...@gmail.com>.
On Jan 26, 2013, at 8:26 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> 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
The JRMP exporter is just a way to use Exporters with standard RMI rather than JERI. You could convert that into a separate distribution that was specific to the Sun/Oracle JVM. Of course, since the things in question are part of RMI, they are probably part of most Java implementations anyway. Definitely separate from JERI.
> 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
Hmm, not as sure about this one. Is this exporter needed for Phoenix? Do you view activation as an important part of JERI, or could that be split out as well?
- Tim
Re: Dirmi might be something to look at
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 25/01/2013 8:25 PM, Dan Creswell wrote:
> On 25 January 2013 05:47, Peter<ji...@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.
Re: Dirmi might be something to look at
Posted by Dan Creswell <da...@gmail.com>.
On 25 January 2013 05:47, Peter <ji...@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....
>
> 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...
> Cheers,
>
> Peter.
>
>
> ----- Original message -----
>> Interesting observation.
>>
>> So if I do a search in google for "customisable rmi" I don't get a hit
>> on River. A quick wander through our docs says we don't present
>> ourselves as having a superior RMI implementation (maybe we do but
>> it's buried deep).
>>
>> We've got some conceptual stuff out there (good) but some grass roots
>> (here's the hot bits of our tech) maybe not so much.
>>
>> So, we're not leveraging the obvious tools for discovery. That said,
>> even if we were, we have to expect some people will reinvent wheels
>> badly. Rob Gingell once observed that “those who do not use Jini are
>> doomed to reinvent it.”
>>
>> On 24 January 2013 04:39, Gregg Wonderly <ge...@cox.net> wrote:
>> > I didn't know about this project. The more things like this I see, the more
>> > it really seems River is hidden from view, more and more.
>> >
>> > http://sourceforge.net/apps/mediawiki/dirmi/index.php?title=Dirmi
>> >
>> > Gregg Wonderly
>
Re: Dirmi might be something to look at
Posted by Peter <ji...@zeus.net.au>.
Perhaps it might be time to make JERI a separate release.
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.
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?
Cheers,
Peter.
----- Original message -----
> Interesting observation.
>
> So if I do a search in google for "customisable rmi" I don't get a hit
> on River. A quick wander through our docs says we don't present
> ourselves as having a superior RMI implementation (maybe we do but
> it's buried deep).
>
> We've got some conceptual stuff out there (good) but some grass roots
> (here's the hot bits of our tech) maybe not so much.
>
> So, we're not leveraging the obvious tools for discovery. That said,
> even if we were, we have to expect some people will reinvent wheels
> badly. Rob Gingell once observed that “those who do not use Jini are
> doomed to reinvent it.”
>
> On 24 January 2013 04:39, Gregg Wonderly <ge...@cox.net> wrote:
> > I didn't know about this project. The more things like this I see, the more
> > it really seems River is hidden from view, more and more.
> >
> > http://sourceforge.net/apps/mediawiki/dirmi/index.php?title=Dirmi
> >
> > Gregg Wonderly
Re: Dirmi might be something to look at
Posted by Dan Creswell <da...@gmail.com>.
Interesting observation.
So if I do a search in google for "customisable rmi" I don't get a hit
on River. A quick wander through our docs says we don't present
ourselves as having a superior RMI implementation (maybe we do but
it's buried deep).
We've got some conceptual stuff out there (good) but some grass roots
(here's the hot bits of our tech) maybe not so much.
So, we're not leveraging the obvious tools for discovery. That said,
even if we were, we have to expect some people will reinvent wheels
badly. Rob Gingell once observed that “those who do not use Jini are
doomed to reinvent it.”
On 24 January 2013 04:39, Gregg Wonderly <ge...@cox.net> wrote:
> I didn't know about this project. The more things like this I see, the more
> it really seems River is hidden from view, more and more.
>
> http://sourceforge.net/apps/mediawiki/dirmi/index.php?title=Dirmi
>
> Gregg Wonderly