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] Commented: (RIVER-316) RFC Library, Application & Class Versioning, Dynamically Mobile Codebases and Classloading enhancements
Date Tue, 25 Aug 2009 02:57:59 GMT

    [ 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

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

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.



> 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, 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.

View raw message