Kepler

this is related to the kar files and dynamically searching for objects in the
kar files. we already have a service registry and storage mechanism, but we
need a standard description for how to store items in each registry and what
metadata is needed per registry.

dynamic class loading issues also need to be worked out for this system. dan
will assist chad on this.

Need to define the archive file format, including manifest structure and
contents, and define its naming convention. We like .kar but it is used
already. Also available are .ksw and .kjar.

Below is a little info about dynamic class reloading in Vergil from Steve
Neuendorffer. Reloading a class is harder than loading it.

At 04:45 PM 9/9/2000 -0700, Steve Neuendorffer wrote:

I've been looking at making Vergil capable of dynamic class reloading.
With a little assistance from some discussions with Jorn, I figured out
what I done incorrectly before. The basic principle is that you can
reload classes If and only if:
1) The classes are NOT accessible to the bootstrap class loader i.e. they
are not listed in the JVM's classpath.
2) The interfaces that are used to refer to those classes are not
reloaded.

For example: we can reload actor.lib.Ramp by removing it from it current
location and putting it somewhere else. This works because all the
important thing about it (such as the actor and port interfaces) are not
reloaded. So I can say:
Classloader c = new URLClassLoader(SOMEURL, getClass().getClassLoader())
and then use that classloader to reflect the ramp actor.
Later I could throw away that class loader and create a new one and the
classes would get reloaded. Notice that the old classes (and instances)
are not removed from the JVM... some other mechanism is resplosible for
keeping track and reinstantiating everything.
I had added support in the MoMLParser for specifying a class loader
before. All I do now is just create a new classloader everytime the
classes in the "dynamicClassPath" need to be reloaded. I haven't checked
these changes in yet, but I will soon.

Steve

We have now decided to only include initial actor loading in this feature.
Reloading, and version and class name conflicts, will be dealt with after the
1.0.0 release. This simplified feature would allow just discovery, download,
and loading of remote actors and workflows.

we decided to wait on this until after the next release.

The Kepler code has been modified to allow for jar files inside of kar containers. At startup, when kars are loaded into the cache, the jar files are copied into the $KEPLER/lib/jars/ directory and dynamically loaded into the classpath. (see http://www.kepler-project.org/Wiki.jsp?page=AddingJarsToKarFiles)

Currently, a problem with loading kar files containing jars from the repository has been reported (as opposed to letting Kepler load them at startup). This bug needs to be investigated and perhaps entered as a new bugzilla bug.

Dan Higgins - November 29, 2007

Concerning comment #7 --- see new bug # 3020

A possible addition to this system would be to have the JVM automatically find jars in a kar file and add them to the classpath when the kar file was loaded.

KAR files will not contain class files or JAR files. Classes and jars will be contained within Kepler modules. KAR files will contain Kepler module dependency information.

KAR files used to contain class files, and wer eboth a successful and necessary part of Kepler 1.0. I am reopening this bug to restore this feature in 2.0 if it has been removed without broader discussion. This decision should be part of the discussion regarding the merging of the KAR and module packaging formats -- I think we should have a single packaging mechanism for archives, eliminating the distinctions and differences between KAR files and modules. Bug is reopened pending further discussion.

This issue needs clarification as to why the module format and the kar format need to be separate. It seems that both are performing the same functionality and that by limiting the kar format to not include jars or classes we are limiting future functionality of kar files and limiting them to a superficial role. Fixing this bug would make bug 4317 obsolete.

Seems this is a long standing issue that requires further discussion.
Any pointers to design documents or similar?

Bertram

Currently evaluating the necessity of this based on further documentation and group discussion.

This can be talked about further after the 2.0 release.

did i miss something yesterday? - we are dropping a feature that was in 1.0.

(In reply to comment #15)

This can be talked about further after the 2.0 release.

Umm, you're right. I was triaging bugs and made a couple mistakes. I'll put this back to 2.0.

This is a controversial design decision and should not be in 2.0.

Including jars in KAR files is NOT a feature. It is an implementation detail.

The feature or requirement is this: to allow individuals to distribute necessary jar files with the actors they develop.

In my view, this requirement should be implemented through modules.

More generally, we should be careful to distinguish between requirements and implementation details. Having jars in KAR files is NOT a requirement. It is a mere implementation detail that has been proposed to achieve a particular objective.

It was agreed that the solution to this is to create a java utility for converting KAR files to Kepler modules. See bug 4702

Original Bugzilla ID was 1750