Jeff Genender wrote:
Jason Dillon wrote:
I still think that G could do with a tiny bootstrap JVM to handle all of
the required flags and properties that are needed now for the server to
opperate properly (and in a platform neutral manner). This could also
be used to spawn clones or cluster nodes. As well as handling remote
restarts and recovery from JVM crashes.
I'm not sure in practice how it compares to having a [GShell] scripting
environment, but I'll throw this out there anyway: as a plugin developer
writing GBeans anyway, I would probably be happy with being able to
program against system-level concepts in a new plugin-lifecycle GBean.
A simplified example of my new GBean might look something like this:
public class MyPluginLifecycle implements
o.a.g.bootstrap.GeronimoPluginLifecycle {
private final o.a.g.bootstrap.BootstrapGBean bootStrap;
public MyPluginLifecycle(o.a.g.bootstrap.BootstrapGBean bootStrap) {
this.bootStrap = bootStrap;
}
public void onInstall() {
ListString jvmArgs = bootStrap.getJVMArguments();
ListString newJvmArgs = new LinkedListString(jvmArgs);
newJvmArgs.add(-Xbootclasspath/p:my-special-bootjar.jar);
bootStrap.setJVMArguments(newJvmArgs);
// Set system properties
bootStrap.setSystemProperty(my-special-name, my-special-value);
// Other stuff...? bootStrap.getDependencies(),
bootStrap.getVarDir(), etc.?
...
}
public void onUninstall() {
// Remove the -Xbootclasspath/p:my-special-bootjar.jar argument
from the JVM arg list, etc.
...
}
// GBean glue
...
}
Having this would a) be consistent in interface for plugin developers
and b) let the Geronimo core know that it needs to be restarted for a
certain plugin to function properly if it altered something like the JVM
arguments or system properties, and let the user know accordingly. But
it, of course, lacks the good things about [GShell] scripting environments.
Ok...cool...wanna help? ;-)
If we can have a GShell, etc set an env property like JAVA_OPTS, please
how an example and I am all game ;-)
Jeff
I will do what I can since I represent the Terracotta use case Jeff
brought up. I believe I read earlier that GShell is in a sandbox (along
with the portals code I need to use for the GUI half of the plugin),
would it be possible to get a new sandbox project of these two projects
together, or otherwise make them work together?
In the meantime I will start experimenting with the portals code to
cover the first half of the Terracotta plugin, then as the scripting
half shakes out I can be a guinnea pig.
Nat
