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 Tue, 17 Jul 2007 04:33:38 GMT
Can you provide a wee bit detail on hat the use cases are you have in  
mind?  I'm still a bit fuzzy what you are going for.


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