[SDM-SPA] Re: [kepler-dev] downloadable actors
berkley at nceas.ucsb.edu
Fri Apr 2 08:51:46 PST 2004
The only code I have that relates to this is in the prototype actor
builder classes. Unfortunately, i still have not been able to get class
reloading (reloading a class after it's already loaded) to work, but
dynamic class compilation and loading does work. Check out the code in
the kepler/src/org/ecoinformatics/seek/workflow directory. Specifically
The jedit model for getting plugins is basically that they have a gui
built into the program where you can go and download/update/remove new
plugins for the system. Jedit, however, does not dynamically load the
plugins, you have to restart the jvm for the changes to take place. I'm
not sure why they do that, because the classes could easily be loaded at
runtime. It is a very easy system for organizing optional components
let me know if you have any questions about that code. hopefully I'll
be able to get back to working on this sometime after our May meeting.
Xiaowen Xin wrote:
> Hi Matt,
> I have never used JEdit, but I will check it out. Thanks for the
> I have not seen Chad's code; can you tell me which specific parts I
> should look at?
> On Wed, 2004-03-31 at 13:20, Matt Jones wrote:
>>This is a great idea, and one that I think will be critical in a variety
>>of contexts. We plan in SEEK to have many actors that are located
>>elsewhere, and users will need to be able to move the code into their
>>system, or, possibly more importantly, move the actor code to a remote
>>system, for execution. Chad has been working on the ClassLoader issues
>>associated with dynamically loading and reloading classes at runtime
>>from within Kepler, and we've had a number of proposed ways to handle
>>this. I think one of the best examples is the way in which plugins for
>>JEdit are downloaded and installed. It is seamless for the user -- you
>>should check it out. But keep in mind that we will need to be able to
>>also export code to a remote system as well. Also, as this is an
>>important area of intersection with the work Chad has already started,
>>it would be nice if we could work together on it. Have you reviewed
>>Chad's code on this topic?
>>Xiaowen Xin wrote:
>>>Something that we'd like to implement as part of SPA/Kepler is an Actor
>>>Repository with some actors that we don't include as part of the normal
>>>distribution. So people can go there, and download additional actors.
>>>What do you all think is a good mechanism for doing this?
>>>More specifically, we could simply distribute a tarball that includes
>>>the actor source code, class file, and xml configuration file, ask the
>>>user to unpackage it in a certain directory that's in her classpath.
>>>Then, ask the user to import that configuration file. After doing this,
>>>the actor will get inserted into "~/.ptolemyII/user library.xml", so the
>>>next time the user runs SPA/Kepler, the system will automatically load
>>>However, this method seems to be quite complicated from a user
>>>perspective. It would be ideal to simply have the users download one
>>>file, put it in a certain directory, and the system automatically loads
>>>it at startup.
>>>Dave and I have been thinking that we could potentially distribute these
>>>actors as .jar files, that have the source, class file, and
>>>configuration file all within. The user could put this jar file in
>>>~/.ptolemyII/ and the system should automatically load it at startup.
>>>On the downside, the implementation of this might be somewhat involved.
>>>We would need to execute something that finds all jar files in
>>>~/.ptolemyII/ and create our own classloader that has the jar files in
>>>its classpath. Then we would need to somehow add the newly found actors
>>>to the treeview at the lefthand side.
>>>Do you all know of any built-in mechanisms that can help do this?
>>>kepler-dev mailing list
>>>kepler-dev at ecoinformatics.org
More information about the Kepler-dev