[jira] Commented: (RIVER-316) RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and Classloading enhancements

["Peter Firmstone (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747197#action_12747197 ] 

Peter Firmstone commented on RIVER-316:
---------------------------------------

I'm thinking about how I can utilize the existing code within River for the Package upgrade process.

I've renamed the PersistentObject interface to EvolvingObject to more accurately reflect that object state and methods can change, although I've retained the name PersistentObjectDelegate for the proxy interface that represents it.  All links to a Java Package's Public API interface implementations are routed through PersistentObjectDelegate's 

The Package Upgrade process has some parallels with Remote Proxy's, so there's opportunity for code reuse.

The basic theory is:

All Objects outside a package, remote or local make all calls and reference the packages proxy's that remain in the main application Classloader.  The implementation Objects for an entire package are moved between Classloaders that are made visible to the main application Classloader, when some or all of the classes in the package are updated, the class file versions are distinguished by implementing the VersionedClass interface. The proxy is updated with the latest Object reference after a successful upgrade.

The MarshalledInstance state snapshot of the Package could be stored on disk in the event of failure during the upgrade process also.

net.jini.io.MarshalledInstance can be utilised for the Serialized state of each object during upgrade, the dynamic codebase service can be passed in via MarshalOuputStream.writeAnnotation(String codebaseService);

The code base can be related back to the package name and a package version number, this package will of course rely on other package versions, Perahaps a package version static class can contain the Package version number along with the dependency tree?  The dependency tree contains all the fully qualified class names for all provider classes,  these can be used to determine which packages are required.

I've changed the name of the entire versioning package from org.apache.river.version to org.apache.river.evolution.

Should I require a jar archive for each application package?  Libraries could have multiple packages and exist in one jar and classloader, I'm still thinking about how to distinguish the two lookup methods and how to get library information into the dependency analysis tool? Perhaps using a configuration file?

Knowing the required class files in advance means the dynamic code base service could provide only those class files necessary (compressed of course). 

The local Classloader would need to check the existence locally of all class files in the dependency array.  This seems too much responsibility for a Classloader however, so I'm open to suggestions on how to split the class loader up.

Cheers,

Peter.



> RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and Classloading enhancements
> -------------------------------------------------------------------------------------------------------
>
>                 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, VersionedDynamicClassesRev6.tgz, VersionedDynamicClassesRev7.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.