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, 11 Sep 2007 01:17:00 GMT
Hehehe...Jason...messing with you is like going to Disneyland...all fun ;-)

Dude...you rock :-)  Keep up the awesome work!

Jefff

Jason Dillon wrote:
> 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