river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: MarshalledInstance
Date Sat, 17 Apr 2010 06:18:29 GMT
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 <jini@zeus.net.au> 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.
>>     
>
>   


Mime
View raw message