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: Cooperative Distributed computing - Versioning over time - Container Metadata.
Date Tue, 20 Oct 2009 22:42:55 GMT
Gregg Wonderly wrote:
> My changes to reggie to provide "never preferred classes" changed 
> MarshalledWrapper and EntryRep to implement
> public interface MarshalledDataAccess<T> {
>     public T getUnmarshalledData() throws IOException, 
> InstantiationException,
>             ClassNotFoundException, IllegalAccessException ;
>     public List<String> getClassNames();
> }
> There is still some other work that I need to finalize in these 
> changes to get service objects to always have this information (there 
> are complex threads of execution and MarshalledObject use).
> I made EntryRep work, and that was the big thing that I needed, so I 
> stopped at that point.
> Creating an interface, such as the above, and putting it into play 
> would be helpful I think.
> I also still believe that we really should change lookup to use 
> unmarshalled data objects (these changes are visible at 
> http://reef.dev.java.net) so that we can then plug in unmarshalling 
> contexts and metadata transport pieces to make services have enough 
> plug-ability that we can provide for registration and discovery of 
> other types of "enviroments" than just what DiscoveryV1 and V2 provide.
> Gregg Wonderly
You know what, your right.  Reggie is implementation specific.  We need 
to change that.

We need a place on svn for River 3.0 where we can make these changes and 
experiment, perhaps using a minimal subset of the current codebase for 
clarity while we experiment.

What components we should initially include?

The AR2 codebase is ready for release apart from some minor changes to 
testing that I haven't quite gotten around to yet, no good holding up 
productivity of fertile minds in the mean time...  Its safe to branch.



> Calum Shaw-Mackay wrote:
>>> Interesting.
>>> Perhaps Marshalled object instances should also be decorated.
>> Yeah you'd need somewhere to start, and as I mentioned below about
>> transparency, you'd possibly need a
>> DEFAULT or CURRENT version, because if you're bringing in an object
>> foreign to the VM, and you're using
>> static analysis, you'd need to have the bytecodes available to
>> actually compare it against, having an initial
>> version identifier would give it a head start in terms of performance,
>> and you don't want to brute-force
>> hammer the network bringing in multiple dl jars, for a class that has
>> not been seen in any version in this JVM session
>> I think the more 'hints' you could provide to the classloader, through
>> either compatible version ranges or soft links
>> the better.
>>>> Whichever way you want to tackle this, you'll need it to be as
>>>> transparent a mechanism as possible so that service/bundles/clients
>>>> that don;t specify versions work as they always have,
>>> Thanks Calum,  good point, when version metadata doesn't exist, the 
>>> results
>>> from Static Analysis alone could be utilised to find API compatible 
>>> import
>>> packages.  I guess classes lacking version metadata could be treated as
>>> version 0.  If someone later decides to add version metadata, 
>>> perhaps after
>>> correcting a bug, the higher versioned package would be preferred, 
>>> provided
>>> it remains API compatible and shares the same fully qualified 
>>> package name.
>> Yeah I'd say a DEFAULT (i.e. 0, although that itself may go through
>> changes in time) and perhaps symlink-type versioning including a
>> In a way, what you don't want is to break compatibility unnecessarily.
>> Calum

View raw message