If you think of anything Gregg, let me know, your
CodebaseAccessClassLoader has certainly assisted.
Jeri provides some pretty good abstractions, and we have
MarshalledInstance instead of MarshalledObject, however JERI re-uses
many Exceptions from RMI, the good news is that they all extend
java.rmi.RemoteException, which is available in CDC, so we could create
our own alternative Exceptions that extend RemoteException, and throw
these instead, this won't break Binary compatibility, but it will break
compile time compatibility, which won't require much change anyway. It
will affect existing application exception code handling, maybe pushing
the exception further up until a RemoteException is caught.
I'm looking at replacing MarshalledObject with MarshalledInstance and
depreciating the methods containing MarshalledObject, the depreciated
methods won't be included in the CDC release and CDC will need it's own
Serialized form compatible implementation of MarshalledInstance.
I've created an ToMOOutputStream, that converts a
net.jini.io.MarshalledObject into a java.rmi.MarshalledObject in a
stream of Objects. I've done this so I can maintain Serialization
backward compatibility where class internal state has been published by
Serialization. The only reason I can get away with it is java's
ObjectSreamClass is also Serializable, so it too is tied to it's
internal implementation & I'm using reflection to modify it.
Incidentally, that's why I like the Serialization Proxy Pattern.
There's another Serialization library I'm investigating called kryo that
is much faster and smaller than java's Serialization, I'm thinking about
creating a JERI implementation for it, however it would need some
additional massaging to suit a distributed environment. With some
slight modification, it could use public declared constructors during
deserialization.
I also need some way to have specific implementations of some classes
for CDC, however I don't want to duplicate files unnecessarily as this
risks platform diversion and increases maintenance, any suggestions for
the build scripts?
Cheers,
Peter.
Gregg Wonderly wrote:
What I would like to see is a mechanism for completely extracting the use of
the java.rmi package use into an SPI like mechanism. The ability to then plug
in some other details or more limited environments like those would be possible.
I don't know any details, but I suspect that some of the use of RMI stiff was
left over from the JSRs and maybe some was there as preparation for another
eventual JSR attempt.
In the end, RMI ended up not getting as much support, from the top brass and in
the Sun Developer Advisory Council meetings, I detected some personality
conflicts that were probably also a factor. Jonathan eliminated some of
those...
Gregg Wonderly
Sent from my iPad
On Apr 16, 2010, at 6:44 AM, Peter Firmstone <[email protected]> wrote:
Hi,
I'm grappling with the Apache River / Jini public API and dependency problems.
I'm looking at what's required to support a subset of Apache River on the Java
CDC Personal Profile (available on Blue Ray players and Amazon Kindle, both of
which have networking and sufficient resources), however there are some issues
which I have to work around:
* Personal Profile doesn't contain the full RMI implementation
components http://java.sun.com/javame/reference/apis/jsr216/
* Apache River has parts of the RMI implementation in Jini's public API.
I'm thinking of ways to deprecate some methods, excluding them from Java CDC,
while keeping the depreciated methods on Java SE
,
My intent is that I'd like Java CDC Personal Profile to be able to participate
in a djinn using dynamic classloading to provide and consume simple services
and UI. Nodes running Java 5 or later can provide lookup services or any
other service that might benefit from java 5 or later language features, I just
want to support the absolute bare essentials to provide or consume basic
services on java CDC.
JSR 66, the RMI spec for Java CDC is an optional api and not included in
Personal Profile, it also appears that the reference implementation is no
longer available from either Sun or IBM.
So which parts of net.jini.* should be included in a release artifact for Java
CDC Personal Profile?
I would prefer if the core release artifact supported all platforms from CDC
up, however maintaining backward binary compatibility in SE is important, so
that may not be possible.
What are the consequences of leaving out the following packages in a Java CDC
profile?
* net.jini.activation
* net.jini.iiop
* net.jini.jrmp
* net.jini.loader.pref
The components of RMI available in Personal Profile are:
* java.rmi.Remote
* java.rmi.RemoteException
* java.rmi.AccessException
* java.rmi.AlreadyBoundException
* java.rmi.NotBoundException
* java.rmi.UnexpectedException
* java.rmi.registry.Registry
The components of RMI missing from Personal Profile are:
* java.rmi.activation.*
* java.rmi.server.*
* java.rmi.dgc.*
* java.rmi.Naming
* java.rmi.RMISecurityManager
* java.rmi.ConnectException
* java.rmi.ConnectIOException
* java.rmi.MarshalException
* java.rmi.NoSuchObjectException
* java.rmi.RMISecurityException
* java.rmi.ServerError
* java.rmi.ServerException
* java.rmi.ServerRuntimeException
* java.rmi.StubNotFoundException
* java.rmi.UnknownHostException
* java.rmi.UnmarshalException
* java.rmi.registry.RegistryHandler
* java.rmi.registry.LocateRegistry
The affected remaining components are:
net.jini.io.MarshalledInstance
net.jini.discovery.LookupDiscoveryService
net.jini.core.lookup.ServiceRegistrar
net.jini.core.event.RemoteEvent
net.jini.jeri.BasicInvocationHandler
Apache River's public API that contains parts of java RMI missing from CDC:
(MarshalledInstance is a return type for other classes, CDC needs it's own
implementation that doesn't depend on java.rmi.MarshalledObject)
net.jini.io.MarshalledInstance
public MarshalledInstance(java.rmi.MarshalledObject<T> mo)
public java.rmi.MarshalledObject<T> convertToMarshalledObject()
RemoteEvent get's used everywhere and MarshalledObject is part of it's
serialized form, I have a solution for this).
net.jini.core.event.RemoteEvent
public MarshalledObject getRegistrationObject()
This interface is a little tougher, as there is only one method.
net.jini.discovery.LookupDiscoveryService
public LookupDiscoveryRegistration register(String[] groups,
LookupLocator[]
locators,
RemoteEventListener
listener,
MarshalledObject
handback,
long leaseDuration)
One of the exceptions thrown is java.rmi.ConnectException, which is a subclass
of RemoteException, although not available in CDC, however.
net.jini.jeri.BasicInvocationHandler
private static RemoteException wrapSafeIOException(IOException ioe,
ObjectEndpoint oe)
Exporter throws an java.rmi.server.ExportException
net.jini.export.Exporter
public Remote export(Remote impl) throws ExportException
I'll commit shortly so you can see what I'm up to.
Cheers,
Peter.
