river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Firmstone (JIRA)" <j...@apache.org>
Subject [jira] Updated: (RIVER-316) RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and Classloading enhancements
Date Tue, 28 Jul 2009 03:26:14 GMT

     [ https://issues.apache.org/jira/browse/RIVER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Peter Firmstone updated RIVER-316:

    Attachment: VersionedDynamicClassesRev2.tgz

I'm experimenting with some interfaces for programmers to be able to upgrade their application's
classfiles dynamically in a djinn, the API will depend on a DynamicVersioningClassLoader that
migrates all objects in a package from one ClassRealm (ClassWorlds Terminology) to another,
when at least one remote object that is eligible for an updated class file is received, or
a package Lease expires and upgraded class files are discovered.

The interfaces that fundamentally model the types of Objects and Class files that may exist
in a Package are:

VersionedPublicClass extends ObjectIdentity, ObjectPreservedOnUpdate, VersionedClass - For
classes that are publicly visible within a djinn.
VersionedPackagePrivateClass extends ObjectPreservedOnUpdate, VersionedClass - For package
private classes that need their object state preserved on upgrades, but don't require visibility
outside their Package's ClassRealm.
VersionedClass - A version identity for the programmer, also used for Classes that don't require
their state preserved, to determine later upgrade versions within a package.

ObjectPreservedOnUpdate - extends Serializable - Indicates that the Object's contents are
to be preserved during transition between ClassLoaders
ObjectIdentity - A unique identifier for a distributable object, a metaphor to local JVM objects
that have their instance and reference for identity.

MobileObjectDelegate - A Wraper implementation of the interface methods of the corresponding
VersionedPublicClass implementation object it wraps, its responsibility is to track the VersionedPublicClass
Object's movement between ClassRealms (classloaders) and request class file update's from
the DynamicVersionClassLoader.  The DynamicVersionClassLoader will be responsible for keeping
a WeakHashMap of MobileObjectDelegates to notify other MobileObjectDelegates to request their
class file updates within a package.  I haven't decided on the rules for creation of MobileObjectDelegates
to distinguish between new unmarshalled objects and the update of class files for Objects
that already exist locally.

VersionedPublicClass - Designed to be extended only by other interfaces that a programmer
develops, it cannot be implemented directly as an Object's Type will change when it transitions
between Package ClassRealm's (ClassLoader's).  This restriction is limited solely to VersionedPublicClass.

Builder<Interface> - An Builder interface for VersionedPublicClass implementations,
so Class / Object implementations don't form dependency's on implementations of interfaces
extending VersionedPublicClass, that would occur from strong references returned by constructors,
depending upon the interface instead.  One Builder for a particular interface might be suitable
for use in many implementing Classes.  Note that a Builder implementation can implement multiple
interfaces also.

> RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and Classloading
> -------------------------------------------------------------------------------------------------------
>                 Key: RIVER-316
>                 URL: https://issues.apache.org/jira/browse/RIVER-316
>             Project: River
>          Issue Type: New Feature
>          Components: net_jini_loader
>         Environment: All
>            Reporter: Peter Firmstone
>         Attachments: classworlds-1.0-src.zip, Java Classloader issues relating to Jini
smli_tr-2006-149.pdf, VerionedDynamicClassesRev1.tgz, VersionedDynamicClasses.zip, VersionedDynamicClassesRev2.tgz
> Request for Comments:
> Proposal to add support for Dynamic Mobile Codebases and Application fine grained class
versioning as well as Coarse grained Library versioning , to enable River User devolopers,
to provide distinction between classes with the same fully qualified class name when code
differences created by refactoring packages or library updates break backward compatibility
between classes contained within that library or package.  ClassWorlds can be used to segregate
ClassRealms for application packages and different library versions.
> A dependency tree array object (contains dependency references between classes, fully
qualified class names are stored as String objects) returned by the new ClassDepend tool (replacement
of classdep functionality) may be suitable (with some modification) for recording class versioning,
for later navigation of the codebase for class version verification, perhaps this could be
stored in serialized form with the codebase.
> The ASM library might be used to modify existing, externally sourced library class file
bytecodes to add a LIBRARYVERSIONID static final field, with an accessor method, for library
code used in codebases, to mark the class files with the library release version.
> serialVersionUID (when it exists), along with the CLASSVERSION static field, might be
used to determine the dependency and backward compatibility of classes in a codebase, this
information could be stored in the dependency tree along with the CLASSVERSION, fully qualified
class name and class file checksum.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message