geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Ideas on a rc.d kind of directory
Date Tue, 17 Jul 2007 04:55:33 GMT
How does the script know to pick it up.  Got a cli example of how the  
invoke would look?

--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