Re: Ideas on a rc.d kind of directory
Don't make me open up a can of whoop-ass now... --jason On Sep 10, 2007, at 6:17 PM, Jeff Genender wrote: 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. U...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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
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. >> >> U...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 <[EMAIL PROTECTED]> >>> 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
Re: Ideas on a rc.d kind of directory
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. U...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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
Jason Dillon wrote: > Aighty... I'm gonna stop waiting for feedback and implement this stuff > for all assemblies. U...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 <[EMAIL PROTECTED]> > 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
Re: Ideas on a rc.d kind of directory
Aighty... I'm gonna stop waiting for feedback and implement this stuff for all assemblies. --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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> 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 >> >>
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
FYI, I've gotten my POC using GShell for this ready... I'm planning on merging the changes into server/trunk today, though I'm not going to hook it up to the default assemblies just yet. Instead I'm going to create a new assembly to allow folks to play with it first and then we can talk about making it the default. More email on how all this stuff works in a wee bit. Cheers, --jason On Jul 19, 2007, at 7:28 AM, Jeff Genender wrote: Lets let Jason chime in here as I think he volunteered to stitch a lot of this together. Jeff Donald Woods wrote: Could we use Jakarta commons-launcher, which uses a subset of ANT? We'd probably have to make a few changes, so it would use the existing manifest settings in the server/client.jar and to handle our multiple server instance directory structure. -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
Re: Ideas on a rc.d kind of directory
Maybe a few more thoughts on this... What I am thinking of is a relatively small JVM which is a process controller. With some basic administration muck built into it to start, stop, kill, list, fork, spawn, clone, blah, blah... server processes... or if needed any support processes. IMO that is a bit more than what the commons-launcher bits do, though probably whatever the start bits do will most certainly end up re-using the ant- launcher bits, as that code is already really solid for starting up new JVM instances. The controller process can also serve as a watchdog to make sure processes are responsive and restart them if/when they barf, and if supported periodically tickle them for basic health information etc. This is kinda what I had always envisioned for the g-twiddle stuff way, way, back. Gshell gets us much closer to making that actually happen, though its still a work in progress, but I think that its put together enough to try to implement an example so others might have a better idea for the general vision. Perhaps use of commons-launcher could do as a much shorter-term implementation, though I would rather spend my time working on a few GShell commands and massage the assembly to make it work, then work on trimming down the GShell size, which is already kinda small, but could be smaller if I tried. GShell already has the basic underpinnings to handle most of what I'm thinking of, though the telnet/ssh stuff is being a PITA right now. I may drop that for now and just implement my own tiny shell client over ssl as a work around until I can finally get the ssh support sorted. --jason On Jul 19, 2007, at 7:28 AM, Jeff Genender wrote: Lets let Jason chime in here as I think he volunteered to stitch a lot of this together. Jeff Donald Woods wrote: Could we use Jakarta commons-launcher, which uses a subset of ANT? We'd probably have to make a few changes, so it would use the existing manifest settings in the server/client.jar and to handle our multiple server instance directory structure. -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
Re: Ideas on a rc.d kind of directory
On Jul 19, 2007, at 7:19 AM, Donald Woods wrote: Could we use Jakarta commons-launcher, which uses a subset of ANT? Subset of ant? I just downloaded the 1.1. release, and it looks like all of ant is in the lib/* Which totals up to 3m of stuff, in addition to the ~76k in bin/. I'd imagine it might not need all that ant fluff, wonder why they ship it like that though :-( --jason
Re: Ideas on a rc.d kind of directory
On Jul 19, 2007, at 7:19 AM, Donald Woods wrote: Could we use Jakarta commons-launcher, which uses a subset of ANT? Maybe... We'd probably have to make a few changes, so it would use the existing manifest settings in the server/client.jar and to handle our multiple server instance directory structure. Almost certainly... --jason
Re: Ideas on a rc.d kind of directory
Lets let Jason chime in here as I think he volunteered to stitch a lot of this together. Jeff Donald Woods wrote: > Could we use Jakarta commons-launcher, which uses a subset of ANT? > We'd probably have to make a few changes, so it would use the existing > manifest settings in the server/client.jar and to handle our multiple > server instance directory structure. > > > -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 >> >>
Re: Ideas on a rc.d kind of directory
Could we use Jakarta commons-launcher, which uses a subset of ANT? We'd probably have to make a few changes, so it would use the existing manifest settings in the server/client.jar and to handle our multiple server instance directory structure. -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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> > 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
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> 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 >> >>
Re: Ideas on a rc.d kind of directory
On Jul 16, 2007, at 6:25 AM, Kevan Miller wrote: I think it should be realativly easy to setup a POC if folks are interested. Sounds great and agreed on the long-term direction. I could see a simple script-based change to enable in the short-term... Before I got whip up some magic lemme get some more input on what Jeffs use cases are... so I'm clear what we are talking about ;-) 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 ;-) Heh. Simply your subconscious giving your id the necessary rationalization for getting an iPhone... Heh, well it worked. I had been using my blackberry for days after I got the iPhone and now I'm using the Jesus Phone much, much more. Love it but... I need to work on a better way to filter mail getting down to my iPhone... There's too much ATM... Ya, I need a mass delete. :-( --jason
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
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.
>>
I'm not sure in practice how it compares to having a [GShell] scripting
environment, but I'll throw this out there anyway: as a plugin developer
writing GBeans anyway, I would probably be happy with being able to
program against system-level concepts in a new plugin-lifecycle GBean.
A simplified example of my new GBean might look something like this:
public class MyPluginLifecycle implements
o.a.g.bootstrap.GeronimoPluginLifecycle {
private final o.a.g.bootstrap.BootstrapGBean bootStrap;
public MyPluginLifecycle(o.a.g.bootstrap.BootstrapGBean bootStrap) {
this.bootStrap = bootStrap;
}
public void onInstall() {
List jvmArgs = bootStrap.getJVMArguments();
List newJvmArgs = new LinkedList(jvmArgs);
newJvmArgs.add("-Xbootclasspath/p:my-special-bootjar.jar");
bootStrap.setJVMArguments(newJvmArgs);
// Set system properties
bootStrap.setSystemProperty("my-special-name", "my-special-value");
// Other stuff...? bootStrap.getDependencies(),
bootStrap.getVarDir(), etc.?
...
}
public void onUninstall() {
// Remove the "-Xbootclasspath/p:my-special-bootjar.jar" argument
from the JVM arg list, etc.
...
}
// GBean glue
...
}
Having this would a) be consistent in interface for plugin developers
and b) let the Geronimo core "know" that it needs to be restarted for a
certain plugin to function properly if it altered something like the JVM
arguments or system properties, and let the user know accordingly. But
it, of course, lacks the good things about [GShell] scripting environments.
> 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
I will do what I can since I represent the Terracotta use case Jeff
brought up. I believe I read earlier that GShell is in a sandbox (along
with the "portals" code I need to use for the GUI half of the plugin),
would it be possible to get a new sandbox project of these two projects
together, or otherwise make them work together?
In the meantime I will start experimenting with the portals code to
cover the first half of the Terracotta plugin, then as the scripting
half shakes out I can be a guinnea pig.
Nat
Re: Ideas on a rc.d kind of directory
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? ;-) Ya, of course... I need to get away from build tck automation crap and work on some real software, cause my brain is starting to turn to jelly :-P If we can have a GShell, etc set an env property like JAVA_OPTS, please how an example and I am all game ;-) Well, it can't really do it now, but should be easy enough to whip it up. Let me ponder for a wee bit and then I'll get back to you. --jason
Re: Ideas on a rc.d kind of directory
How about bin/scripts ? Jeff Matt Hogstrom wrote: > > On Jul 16, 2007, at 3:17 AM, Jason Dillon wrote: > >> Why in bin/* ? >> > > Only cause they are related to scripts.
Re: Ideas on a rc.d kind of directory
On Jul 16, 2007, at 3:17 AM, Jason Dillon wrote: Why in bin/* ? Only cause they are related to scripts.
Re: Ideas on a rc.d kind of directory
On Jul 16, 2007, at 3:32 AM, 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. 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. Sounds great and agreed on the long-term direction. I could see a simple script-based change to enable in the short-term... --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 ;-) Heh. Simply your subconscious giving your id the necessary rationalization for getting an iPhone... I need to work on a better way to filter mail getting down to my iPhone... There's too much ATM... --kevan
Re: Ideas on a rc.d kind of directory
Donald Woods wrote: > > > Jeff Genender 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. > > I know Jason would be in favor of dropping the complicated .sh/.bat > files we have now, as we have seen several breakages between them this > release (between the openjpa agent, handling spaces in paths on Windows, > file separators, ...) > > My point, was that having to provide 2 scripts per extension (Unix and > Windows) would be troublesome for some, like all you Mac users who hate > Windows :-) Im am fine with it being in GShell or Groovy. If someone can have these scripts set environment variable and/or preload the geronimo.sh with ones set from these scripts, then I am totally fine with this. Jeff > > -Donald >> >>> >>> -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 >> >>
Re: Ideas on a rc.d kind of directory
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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
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. 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 <[EMAIL PROTECTED]> 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
Re: Ideas on a rc.d kind of directory
*giggle* --jason On Jul 14, 2007, at 7:50 AM, Matt Hogstrom <[EMAIL PROTECTED]> wrote: On Jul 13, 2007, at 8:13 PM, Jeff Genender wrote: Does that make me Marc of geronimo? ;-) You mean because we automatically discount what you say? :)
Re: Ideas on a rc.d kind of directory
Why in bin/* ? *** Btw my email box was full so I may have missed some discussion. Should be happier now though. --jason On Jul 14, 2007, at 7:54 AM, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I like the idea a lot. How would this work mechanically? Are you thinking of $G/bin/rc.d/ ? If so, the convention of prepending script names with a numbered prefix to help with ordering would useful to start with as well. Great idea. On Jul 13, 2007, at 7:04 PM, Jeff Genender wrote: 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.
Re: Ideas on a rc.d kind of directory
IMO, the less native platform scripts we have the better. I'm defs against adding new ones... and really interested in removing the ones we currently have. If only Microsoft would ship a /bin/sh then I'd be happy to keep around a single set of scripts... but ya, thats not gonna happen :-( --jason On Jul 15, 2007, at 11:29 AM, Donald Woods wrote: Jeff Genender 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. I know Jason would be in favor of dropping the complicated .sh/.bat files we have now, as we have seen several breakages between them this release (between the openjpa agent, handling spaces in paths on Windows, file separators, ...) My point, was that having to provide 2 scripts per extension (Unix and Windows) would be troublesome for some, like all you Mac users who hate Windows :-) -Donald -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
Re: Ideas on a rc.d kind of directory
Jeff Genender 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. I know Jason would be in favor of dropping the complicated .sh/.bat files we have now, as we have seen several breakages between them this release (between the openjpa agent, handling spaces in paths on Windows, file separators, ...) My point, was that having to provide 2 scripts per extension (Unix and Windows) would be troublesome for some, like all you Mac users who hate Windows :-) -Donald -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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Ideas on a rc.d kind of directory
I like the idea a lot. How would this work mechanically? Are you thinking of $G/bin/rc.d/ ? If so, the convention of prepending script names with a numbered prefix to help with ordering would useful to start with as well. Great idea. On Jul 13, 2007, at 7:04 PM, Jeff Genender wrote: 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.
Re: Ideas on a rc.d kind of directory
On Jul 13, 2007, at 8:13 PM, Jeff Genender wrote: Does that make me Marc of geronimo? ;-) You mean because we automatically discount what you say? :)
Re: Ideas on a rc.d kind of directory
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 >> >>
Re: Ideas on a rc.d kind of directory
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. 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. -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 smime.p7s Description: S/MIME Cryptographic Signature
Re: Ideas on a rc.d kind of directory
Hi, I believe it is a great idea to have a kind of hook directory defining scripts to be executed at specific stages. It seems to me that the current .bat or .sh scripts will become harder and harder to implement, maintain and *test* - AFAIK, there are no tests. It seems to me that a move to a cross-platform scripting language a la Groovy would give us a better mileage. As a matter of fact, the Grails project has defined a very nice way to integrate hook scripts provided by plugins into the runtime configuration of a grails app - see http://grails.codehaus.org/Runtime +Configuration+Plugins for more details. What do you think about porting .bat and .sh scripts to groovy scripts? Thanks, Gianny On 14/07/2007, at 9:04 AM, 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
Re: Ideas on a rc.d kind of directory
On Jul 13, 2007, at 5:13 PM, Jeff Genender wrote: Jason Dillon wrote: I was kinda against this kinda thingy way back in the days of the boss-of-j, but I'm interested to hear more how you think it might work... since I just wrote off anything Marc said as crap automatically :-P Does that make me Marc of geronimo? ;-) No, you aren't a prick :-P --jason
Re: Ideas on a rc.d kind of directory
Ok...maybe even not a script...maybe something that works similar to how the sysconfig system on Unix works. A directory that contains "settings files" or something that allows us to set environment variables. Like a drop in text file: JAVA_OPTS=-xbootclasspath-Xbootclasspath/p:var/terracotta/tc.jar Although this is cool, at some point, someone is gonna want to run something though and we may wish to go back to scripting ;-) The positive on these text files is its automatically mostly cross platform. Downside is we cant run anything...just an idea... I would like to hear others' ideas. Jeff Jason Dillon wrote: > I was kinda against this kinda thingy way back in the days of the > boss-of-j, but I'm interested to hear more how you think it might > work... since I just wrote off anything Marc said as crap automatically :-P > > --jason > > > On Jul 13, 2007, at 4:17 PM, David Jencks wrote: > >> >> On Jul 13, 2007, at 7:04 PM, 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? >> >> How cross platform can we make this? >> >> I'm not sure I know what kinds of things you expect this to be used >> for, so if you can provide some more concrete examples I'd appreciate >> it. I'm wondering if this is the kind of stuff that we've been taking >> care of so far with e.g. the SystemPropertiesGbean and >> DirectoryInitializationGBean. >> >> thanks >> david jencks >> >>> >>> Jeff >>
Re: Ideas on a rc.d kind of directory
Jason Dillon wrote: > I was kinda against this kinda thingy way back in the days of the > boss-of-j, but I'm interested to hear more how you think it might > work... since I just wrote off anything Marc said as crap automatically :-P > Does that make me Marc of geronimo? ;-) > --jason > > > On Jul 13, 2007, at 4:17 PM, David Jencks wrote: > >> >> On Jul 13, 2007, at 7:04 PM, 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? >> >> How cross platform can we make this? >> >> I'm not sure I know what kinds of things you expect this to be used >> for, so if you can provide some more concrete examples I'd appreciate >> it. I'm wondering if this is the kind of stuff that we've been taking >> care of so far with e.g. the SystemPropertiesGbean and >> DirectoryInitializationGBean. >> >> thanks >> david jencks >> >>> >>> Jeff >>
Re: Ideas on a rc.d kind of directory
David Jencks wrote: > > On Jul 13, 2007, at 7:04 PM, Jeff Genender wrote: >> 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? > > How cross platform can we make this? > > I'm not sure I know what kinds of things you expect this to be used for, > so if you can provide some more concrete examples I'd appreciate it. > I'm wondering if this is the kind of stuff that we've been taking care > of so far with e.g. the SystemPropertiesGbean and > DirectoryInitializationGBean. Sure...I'll give you an example and unfortunately the SystemPropertiesGbean and DirectoryInitializationGBean won't work... Terracotta is a great example. They need to set a Java option that sets the boot classpath (-Xbootclasspath) Its something that has to be a part of the command line in order for the JVM to correctly have its base objects instrumented. It would be cool to have their plugin drop a script in a directory that gets picked up when running the app server. This is much better than having it edit our own scripts directly. Hence, if the plugin gets uninstalled, the script is removed and everything is back to the way it was. As for cross platform, I think its up to the plugin developer who needs this capability. Right now we support bat and sh scripts...which I think is enough for us, so this seems like its reasonable to me. I think this is a detail that can easily be handled. But from a Geronimo perspective, we don't care because its our scripts that are firing the subscripts. The impl is left up to the plugin/script developer...let just recommend they offer a sh and bat script. > > thanks > david jencks > >> >> Jeff
Re: Ideas on a rc.d kind of directory
I was kinda against this kinda thingy way back in the days of the boss-of-j, but I'm interested to hear more how you think it might work... since I just wrote off anything Marc said as crap automatically :-P --jason On Jul 13, 2007, at 4:17 PM, David Jencks wrote: On Jul 13, 2007, at 7:04 PM, 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? How cross platform can we make this? I'm not sure I know what kinds of things you expect this to be used for, so if you can provide some more concrete examples I'd appreciate it. I'm wondering if this is the kind of stuff that we've been taking care of so far with e.g. the SystemPropertiesGbean and DirectoryInitializationGBean. thanks david jencks Jeff
Re: Ideas on a rc.d kind of directory
On Jul 13, 2007, at 7:04 PM, 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? How cross platform can we make this? I'm not sure I know what kinds of things you expect this to be used for, so if you can provide some more concrete examples I'd appreciate it. I'm wondering if this is the kind of stuff that we've been taking care of so far with e.g. the SystemPropertiesGbean and DirectoryInitializationGBean. thanks david jencks Jeff
