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 Tue, 17 Jul 2007 12:38:55 GMT


Jason Dillon wrote:
> How does the script know to pick it up.  Got a cli example of how the
> invoke would look?

Pseudo code for geronimo.sh:

scripts = read(bin/scripts);
for each script in scripts do
   call script
endfor

Jeff

> 
> --jason
> 
> 
> On Jul 16, 2007, at 9:45 PM, Jeff Genender wrote:
> 
>> Use case needed now:
>>
>> Terracotta is developing a plugin.  It needs to pass a setting to the
>> JVM (i.e. -xbootclasspath=).  So when the Geronimo script is run, it
>> needs to pick up this "setting" from a script that is installed by the
>> plugin.  The script would normally set a JAVA_OPTS and the geronimo.sh
>> script would then pick this up.
>>
>> These scripts would be installed by plugins (or created by someone), but
>> the great part is, when the plugin is uninstalled, the script goes away,
>> and the options are not set.
>>
>> Did this make sense?
>>
>> Jeff
>>
>>
>>
>> Jason Dillon wrote:
>>> 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.
>>>
>>> --jason
>>>
>>>
>>> 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.
>>>>
>>>> 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