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, 11 Sep 2007 01:03:41 GMT
I meant stop waiting for _more_ feedback :-P

So far its all been good, but its a bigish change so I wanted to wait  
for a bit before I did it.

I've also been sexying up gshell... :-P

--jason


On Sep 10, 2007, at 5:54 PM, Jeff Genender wrote:

>
>
> Jason Dillon wrote:
>> Aighty... I'm gonna stop waiting for feedback and implement this  
>> stuff
>> for all assemblies.
>
> Ummmm...what am I...chopped liver? ;-)
>
>
>>
>> --jason
>>
>>
>> On Sep 9, 2007, at 6:41 AM, Jeff Genender wrote:
>>
>>> No...no reasons...move forward ;-)
>>>
>>> Jeff
>>>
>>> Jason Dillon wrote:
>>>> Hey, have you played with the rc.d bits in the
>>>> assemblies/geronimo-jetty6-javaee5-gshell enough to know if what I
>>>> whipped up will work for you?
>>>>
>>>> Any more comments or suggestions on how that stuff should work?
>>>>
>>>> I think this is done, quite powerful and flexible... though to  
>>>> really
>>>> know for sure we'd need to have a few plugins actually using it to
>>>> augment the Server's bootstrap configuration a?
>>>>
>>>> So... are there any reasons (significant or not) for not moving  
>>>> forward
>>>> with this?
>>>>
>>>> --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