geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: Ideas on a rc.d kind of directory
Date Mon, 16 Jul 2007 13:09:13 GMT


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.

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

> 
> 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 <jgenender@apache.org> 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 setjavaenv.sh 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
>>>>
>>>>

Mime
View raw message