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
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
CURRENT.
In a way, what you don't want is to break compatibility unnecessarily.
Calum
