geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathaniel Harward <nharw...@terracotta.org>
Subject Re: Ideas on a rc.d kind of directory
Date Mon, 16 Jul 2007 21:26:22 GMT
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() {
    List<String> jvmArgs = bootStrap.getJVMArguments();
    List<String> newJvmArgs = new LinkedList<String>(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

Mime
View raw message