Allow KAR files to include jar/class files
The issue of a remote Kepler actor (and workflow) repository has come up every
now and then. It would serve multiple purposes:
- as an actor and service registry for discovery, similar to a UDDI registry for
web services (only better ;-)
- to avoid loading each and every actor when installing Kepler: actors could be
discovered dynamically (with an expanded actor search function), their
interfaces could be loaded into the local users view (so actor signatures become
visible); eventually for "local actors" their code would be loaded from the
remote repository and plugged into the user's local installation.
Note that some actors will require jars from the repository to be downloaded and
plugged-in, while others, most notably WS actors only required to download and
plug-in the interface or a thin "interpreter layer"
- as a community repository for common tasks (semantic annotations for actor and
workflow classification become very important)
A related issue is that of a browsable and searchable data repository.
#1 Updated by Chad Berkley almost 16 years ago
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.
#4 Updated by Christopher Brooks almost 16 years ago
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
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.
#5 Updated by Matt Jones almost 15 years ago
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.
#7 Updated by Dan Higgins almost 13 years ago
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
#11 Updated by Matt Jones over 11 years ago
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.
#12 Updated by Chad Berkley about 11 years ago
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.
#18 Updated by David Welker almost 11 years ago
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.