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 Sat, 14 Jul 2007 13:41:30 GMT


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