geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Ideas on a rc.d kind of directory
Date Sat, 08 Sep 2007 19:59:45 GMT
Hey, have you played with the rc.d bits in the assemblies/geronimo- 
jetty6-javaee5-gshell enough to know if what I whipped up will work  
for you?

Any more comments or suggestions on how that stuff should work?

I think this is done, quite powerful and flexible... though to really  
know for sure we'd need to have a few plugins actually using it to  
augment the Server's bootstrap configuration a?

So... are there any reasons (significant or not) for not moving  
forward with this?


On Jul 16, 2007, at 6:09 AM, 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.
> 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
>> IMO this is critical for uber massive enterprise deployments as  
>> well as
>> smaller scale cluster management.
>> I also think that GShell would be ideal for the base platform for  
>> such a
>> bootstrap JVM.
>> I think it should be realativly easy to setup a POC if folks are
>> interested.
>> --jason
>> P.S. Typed on my iPhone.  Still not quite as fast as my blackberry...
>> But I dropped in beer at the Giants/Doggers game.  Ooops ;-)
>> On Jul 14, 2007, at 6:41 AM, Jeff Genender <>  
>> wrote:
>>> Donald Woods wrote:
>>>> Is this a scenario that would be better handled by the gshell  
>>>> code in
>>>> sandbox or some daemon code that also handles the multiple server
>>>> instance support?
>>>> Thought here, would be gshell could read a standard Java  
>>>> properties file
>>>> for JVM args and then launch the server with them.....
>>> As long as one JVM launches, the other (ie. gshell or groovy can  
>>> start
>>> another instance of a JVM) then this is doable.  Otherwise, this  
>>> won't
>>> work...with my Terracotta example being a reason.
>>>> In my eyes, scripts are a no-go, unless you can make them platform
>>>> neutral and not require users to install a third-party solution  
>>>> like
>>>> Perl (on Windows) to make it work.
>>> We already ship sh and bat code...why would this be a no-go?  If  
>>> this is
>>> the case, then we shouldn't be shipping startup scripts in bat  
>>> and sh
>>> format.
>>>> -Donald
>>>> Jeff Genender wrote:
>>>>> Hi,
>>>>> As we move forward and we integrate with more and more 3rd party
>>>>> products, we will need the ability to be able to change an  
>>>>> environment
>>>>> variable through a plugin, or add a commandline JAVA_OPTS, etc.
>>>>> Currently our startup scripts call the to set  
>>>>> environment
>>>>> properties.  It would really be nice to have the ability to have a
>>>>> "scripts" directory, where all of the scripts get executed before
>>>>> Geronimo is launched.  Why do we want this?
>>>>> As we grow in our plugins, they will need to set environment or  
>>>>> java
>>>>> options set before running G.  They may also have a need to  
>>>>> start or
>>>>> run
>>>>> other outside processes  that are not a part of G.
>>>>> It would be great to allow plugins to install an rc script that  
>>>>> gets
>>>>> executed to do activities before and perhaps after G is run?
>>>>> I would propose we create a scripts directory under bin or  
>>>>> under var
>>>>> that could be similar to init.d, and have it called with start/ 
>>>>> stop,
>>>>> etc.  This way plugins can install specific scripts in these
>>>>> directories
>>>>> for execution.
>>>>> Thoughts?
>>>>> Jeff

View raw message