Re: New GShell-based Geronimo Server launcher now in server/trunk
Cool stuff. I probably should have alerted you to the 2.0 version of Mina has bugs up the wazoo and would have advocated not to use it. I also back ported to 1.1.2 for the AyncHttpClient stuff, and that stabilized everything. Jeff Jason Dillon wrote: Well... me thinks I've finally gotten over the major hump... I had been using Mina 2.x (which is in pre-release right now)... I was using it because it has some synchronous request/response handling muck already there which I kinda needed to implement the remote shell proxy muck. And well, I must have spent like a week digging through code, running tests, rebuilding my tree, and really... going crazy because no matter what I did nothing seemed to behave itself as I needed it to. So I ported and basically re-wrote all that request/response stuff I wanted so I could add debug to it and understand why it was not happy... or try to at least. It really seemed like there was some kind of threading problem or a sync problem but all of the diag I got from logs just made no sense and the results I get from running tests were random at best. Ugh... so anyways, I wanted to use Mina 2.0 for the request/response stuff... which I rewrote anyways... so a little before midnight on the night before the 20th I decided to move Mina 1.1.2 (latest official release). Updated some apis, hacked around a few other bits... and about 10 or 10 minutes into the 20th I had the tcp transports all ported and... um working!!! for the normally async, req/resp and for the stream i/o all at the same time. It was a nice birthday present... such a good feeling to finally get this crap working after going mad over it over the past few days!!! :-) And now over the days past I've fixed up the vm:// transport and fixed some bugs in the req/resp handling which were causing things to puke up insanity in a oh so blissful random form. Um... ya, so I think I've finally mastered... er well, beaten to submission, mina... which I still really like a lot btw... And I've implemented some framework to make using it a little easier for me, probably going to invent some more as I go... but right now... um... it seems to work. Tcp, ssl, vm... all working happy, happy. Message passing along side of stream i/o sitting on top of a few request/response bits to boot. Oh ya... and well, you can actually get a remote shell with this stuff now. Its not 100% functional, but you can connect to a remote server (running a rsh-server command), authenticate (internally it will do some rsa key exchange muck too) and then well, you are running commands on the remote system. And the output comes back to you, and you can 'exit' the remote shell and get back to your local shell. Wee. Its still not done though, all this batting with mina had kept me from finishing up the gshell rsh protocl bits and finishing up the state management and such... but I think I'm past that now, so I really hope to get these loose ends tied up soonish. Its still a bit POC, I'm still learning and adapting to how best to implement this stuff, but I expect the first version to be a just make it work and then after that a bit of refactor to clean things up (which really has how most of the gshell implementation has been going... sans the first week of insane code drops when I wrote most of it). * * * Okay, I'll stop babbling now... my point is... the remoting crapo works... and I think that maybe in another week or so there should be something functional enough for me to integration back into Geronimo. Something like a gsh rsh into a running server (over ssl with authentication) and then maybe a few stupid commands to show vm stats, shutdown or something else. I guess since some peeps are keen for scripting muck I can show how you can use the script command to execute a script on a server too ;-) I'm still working on the 'makecoffee --now' command... :-P Oh, and lastly... and then ya... I'll shut up... If anyone is even remotely interested in any of this crap it would be nice to have another mass of grey matter pondering over some of its present and future... Cheers, --jason PS. Sorry, I couldn't resist... I think that the stuff in there now can probably support a telnet as well as ssh transport impl too. Though I've yet to find an ASL friendly java ssh client+server library to build it with... On Sep 18, 2007, at 3:09 PM, Jason Dillon wrote: Hiya folks... just a quick update on GShell muck... I've been madly hacking on the remote shell support for the past week and well, its really close to being functional. I initially was going to implement a POC over ActiveMQ but that was pissing me off soo much that I decided to peek at what Jeff had done with GShell and discovered how incredibly cool Apache Mina is!! So I've based the remote-shell client/server bits off of Mina and its working out fairly well, though I had to go
Re: New GShell-based Geronimo Server launcher now in server/trunk
Well... me thinks I've finally gotten over the major hump... I had been using Mina 2.x (which is in pre-release right now)... I was using it because it has some synchronous request/response handling muck already there which I kinda needed to implement the remote shell proxy muck. And well, I must have spent like a week digging through code, running tests, rebuilding my tree, and really... going crazy because no matter what I did nothing seemed to behave itself as I needed it to. So I ported and basically re-wrote all that request/response stuff I wanted so I could add debug to it and understand why it was not happy... or try to at least. It really seemed like there was some kind of threading problem or a sync problem but all of the diag I got from logs just made no sense and the results I get from running tests were random at best. Ugh... so anyways, I wanted to use Mina 2.0 for the request/response stuff... which I rewrote anyways... so a little before midnight on the night before the 20th I decided to move Mina 1.1.2 (latest official release). Updated some apis, hacked around a few other bits... and about 10 or 10 minutes into the 20th I had the tcp transports all ported and... um working!!! for the normally async, req/resp and for the stream i/o all at the same time. It was a nice birthday present... such a good feeling to finally get this crap working after going mad over it over the past few days!!! :-) And now over the days past I've fixed up the vm:// transport and fixed some bugs in the req/resp handling which were causing things to puke up insanity in a oh so blissful random form. Um... ya, so I think I've finally mastered... er well, beaten to submission, mina... which I still really like a lot btw... And I've implemented some framework to make using it a little easier for me, probably going to invent some more as I go... but right now... um... it seems to work. Tcp, ssl, vm... all working happy, happy. Message passing along side of stream i/o sitting on top of a few request/ response bits to boot. Oh ya... and well, you can actually get a remote shell with this stuff now. Its not 100% functional, but you can connect to a remote server (running a rsh-server command), authenticate (internally it will do some rsa key exchange muck too) and then well, you are running commands on the remote system. And the output comes back to you, and you can 'exit' the remote shell and get back to your local shell. Wee. Its still not done though, all this batting with mina had kept me from finishing up the gshell rsh protocl bits and finishing up the state management and such... but I think I'm past that now, so I really hope to get these loose ends tied up soonish. Its still a bit POC, I'm still learning and adapting to how best to implement this stuff, but I expect the first version to be a just make it work and then after that a bit of refactor to clean things up (which really has how most of the gshell implementation has been going... sans the first week of insane code drops when I wrote most of it). * * * Okay, I'll stop babbling now... my point is... the remoting crapo works... and I think that maybe in another week or so there should be something functional enough for me to integration back into Geronimo. Something like a gsh rsh into a running server (over ssl with authentication) and then maybe a few stupid commands to show vm stats, shutdown or something else. I guess since some peeps are keen for scripting muck I can show how you can use the script command to execute a script on a server too ;-) I'm still working on the 'makecoffee --now' command... :-P Oh, and lastly... and then ya... I'll shut up... If anyone is even remotely interested in any of this crap it would be nice to have another mass of grey matter pondering over some of its present and future... Cheers, --jason PS. Sorry, I couldn't resist... I think that the stuff in there now can probably support a telnet as well as ssh transport impl too. Though I've yet to find an ASL friendly java ssh client+server library to build it with... On Sep 18, 2007, at 3:09 PM, Jason Dillon wrote: Hiya folks... just a quick update on GShell muck... I've been madly hacking on the remote shell support for the past week and well, its really close to being functional. I initially was going to implement a POC over ActiveMQ but that was pissing me off soo much that I decided to peek at what Jeff had done with GShell and discovered how incredibly cool Apache Mina is!! So I've based the remote-shell client/server bits off of Mina and its working out fairly well, though I had to go and learn about it (which was actually fun-ish, sorta, okay not really so much :-P ). Anyways, I've dug through GCache (which really did help me to understand Mina) as well as some other Mina-based projects and
Re: New GShell-based Geronimo Server launcher now in server/trunk
Hiya folks... just a quick update on GShell muck... I've been madly hacking on the remote shell support for the past week and well, its really close to being functional. I initially was going to implement a POC over ActiveMQ but that was pissing me off soo much that I decided to peek at what Jeff had done with GShell and discovered how incredibly cool Apache Mina is!! So I've based the remote-shell client/server bits off of Mina and its working out fairly well, though I had to go and learn about it (which was actually fun-ish, sorta, okay not really so much :-P ). Anyways, I've dug through GCache (which really did help me to understand Mina) as well as some other Mina-based projects and I've whipped up a fairly simple system (er I think so), which is extensible supports TCP, SSL and VM (er well almost VM), so you can do something like: ./bin/gsh rsh ssl://someserver: or ./bin/gsh rsh tcp://someserver: The same is true for the server side, to be able to accept these rsh commands you could: ./bin/gsh rsh-server ssl://localhost: or ./bin/gsh rsh-server tcp://localhost: etc... I've implemented a RSA-based client-server handshake (similar to what gcache was doing, actually based on what it was doing) to support a decent authentication mechanism. Might eventually hook up some JAAS crapo later, but... ya later. Anyways, right now I'm trying to figure out some small problems with the stream message passing and marshaling, which I hope to get resolved really damn soon, cause this is fricken annoying me. And once that is sorted, a few minor clean up things and the rsh/rsh- server bits should be functional enough to actually use. More to come... Cheers, --jason On Sep 8, 2007, at 12:40 PM, Jason Dillon wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't
Re: New GShell-based Geronimo Server launcher now in server/trunk
Jason Dillon wrote: Anyways... email for any reason. Aighty? Hey Jason, Before I realized the new gshell changes were introduced yesterday I attempted to start the server the old fashioned way using ./geronimo.sh run. This failed due to the assembly not containing the necessary yoko bits in lib/endorsed. As a hack I checked in a change to boilerplate-minimal to add those bits back in lib/endorsed (http://svn.apache.org/viewvc?rev=575357view=rev) so I could get an assembly that would start the old way. BTW, I tried this same change in boilderplate-javaee5 but it didn't have the desired effect on the assemblies. I'm not clear if we intend to keep things working with geronimo.sh or if a similar change was even necessary to start the server using gshell (perhaps it has some magic to dynamically create lib/endorsed?). So please feel free to revert the change, provide recommendations for how I should fix this, or make the necessary corrections to undo any damage I may have done. Now I'm off to play some with cool gshell :-) ... Joe
Re: New GShell-based Geronimo Server launcher now in server/trunk
BTW we should be careful of preserving the work Gianny did a while back to reduce the number of jars that need to be in lib by providing a bootstrap repository. (I don't understand exactly what he did, this might not be exactly right). I was hoping we could take the stax/jaxb jars back out of lib and thought I had an example of this working. thanks david jencks On Sep 14, 2007, at 10:46 AM, Paul McMahan wrote: Looking good. I ran into a couple of CNFE's while trying to install plugins using bin/deploy.sh. It was looking for the stax and jaxb classes. I hacked around that by manually adding the stax and jaxb jars from geronimo/lib to my classpath. Best wishes, Paul On Sep 13, 2007, at 6:11 AM, Jason Dillon wrote: Aighty, I've converted *all* of the assemblies to include the new GShell-based server launcher goodness. I'm still working on cleaning things up and adding more features to the core GShell bits. And some things I'm going to change in direct response to how we end up integrating it into Geronimo. I've already hooked up a custom GShell branding instance which helps change the default welcome text/help text/version muck to be Geronimo specific (and not GShell specific). This is the first real usage of GShell being used to support another application (um, the server) so I imagine that I'll (we'll) learn a little bit about that and refactor the branding bits as we go along. * * * I did a few things... first, I've changed the boilerplate modules to use the assembly module for most of the heavy lifting. And then I've put in the same structure that was in my POC assembly into everything. So that means that everything now has these additional goodies: *Scripts bin/gsh bin/gsh.bat bin/start-server bin/start-server.bat * Boot Jars lib/boot/gshell-bootstrap.jar lib/boot/plexus-classworlds-1.2-alpha-10.jar * Runtime Jars lib/gshell/ant-1.7.0.jar lib/gshell/ant-launcher-1.7.0.jar lib/gshell/geronimo-commands-2.1-SNAPSHOT.jar lib/gshell/groovy-all-1.1-beta-2.jar lib/gshell/gshell-cli-1.0-alpha-1-SNAPSHOT.jar lib/gshell/gshell-embeddable-1.0-alpha-1-SNAPSHOT.jar lib/gshell/jcl104-over-slf4j-1.4.3.jar lib/gshell/slf4j-log4j12-1.4.3.jar * Configuration etc/gsh-classworlds.conf etc/gsh-log4j.properties etc/layout.xml etc/META-INF/plexus etc/META-INF/plexus/plexus.xml * Example RC bits etc/rc.d/start-server,default.groovy And if you run the shell once, then you'll also find this: var/log/gshell.log I've left all of the other goodies there for now too, so for example these both should do very similar things: bin/start-server bin/geronimo run bin/gsh -q start-server * * * I'm not sure if I broke anything in the process, so I'd really appreciate it others could look this stuff over and provide some feedback. I probably did break something... (sorry)... but I can't tell at the moment due to the tree not being buildable. Remember I'm still whacking bits out... but if you think of something you want/need that is related, please send mail (to the list should do as long as the subject looks gshell-ish). My goal is to get *all* of the command-line bits for the server to run through GShell, and use that experience to tighten up the framework and hopefully provide some simple documentation to allow other projects to easily consume the GShell for their application needs. And in the process of doing all that I'm going to get that 'remote-shell' command stuff working at least as a minimal prototype. Might need to ping the network gurus for help after the proto is working to finish up the design and make it truly kick ass :-) Anyways... email for any reason. Aighty? Cheers, --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed
Re: New GShell-based Geronimo Server launcher now in server/trunk
I'm converting all of the assemblies tonight, should be done in another hour or so. But, currently server/trunk is not building due to: snip [INFO] Compiling 18 source files to /Users/jason/ws/geronimo/server/ modules/geronimo-openejb/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.TransactionServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.SecurityServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo /snip So, I can't verify that everything is super happy... --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of
Re: New GShell-based Geronimo Server launcher now in server/trunk
Aighty, I've converted *all* of the assemblies to include the new GShell-based server launcher goodness. I'm still working on cleaning things up and adding more features to the core GShell bits. And some things I'm going to change in direct response to how we end up integrating it into Geronimo. I've already hooked up a custom GShell branding instance which helps change the default welcome text/help text/version muck to be Geronimo specific (and not GShell specific). This is the first real usage of GShell being used to support another application (um, the server) so I imagine that I'll (we'll) learn a little bit about that and refactor the branding bits as we go along. * * * I did a few things... first, I've changed the boilerplate modules to use the assembly module for most of the heavy lifting. And then I've put in the same structure that was in my POC assembly into everything. So that means that everything now has these additional goodies: *Scripts bin/gsh bin/gsh.bat bin/start-server bin/start-server.bat * Boot Jars lib/boot/gshell-bootstrap.jar lib/boot/plexus-classworlds-1.2-alpha-10.jar * Runtime Jars lib/gshell/ant-1.7.0.jar lib/gshell/ant-launcher-1.7.0.jar lib/gshell/geronimo-commands-2.1-SNAPSHOT.jar lib/gshell/groovy-all-1.1-beta-2.jar lib/gshell/gshell-cli-1.0-alpha-1-SNAPSHOT.jar lib/gshell/gshell-embeddable-1.0-alpha-1-SNAPSHOT.jar lib/gshell/jcl104-over-slf4j-1.4.3.jar lib/gshell/slf4j-log4j12-1.4.3.jar * Configuration etc/gsh-classworlds.conf etc/gsh-log4j.properties etc/layout.xml etc/META-INF/plexus etc/META-INF/plexus/plexus.xml * Example RC bits etc/rc.d/start-server,default.groovy And if you run the shell once, then you'll also find this: var/log/gshell.log I've left all of the other goodies there for now too, so for example these both should do very similar things: bin/start-server bin/geronimo run bin/gsh -q start-server * * * I'm not sure if I broke anything in the process, so I'd really appreciate it others could look this stuff over and provide some feedback. I probably did break something... (sorry)... but I can't tell at the moment due to the tree not being buildable. Remember I'm still whacking bits out... but if you think of something you want/need that is related, please send mail (to the list should do as long as the subject looks gshell-ish). My goal is to get *all* of the command-line bits for the server to run through GShell, and use that experience to tighten up the framework and hopefully provide some simple documentation to allow other projects to easily consume the GShell for their application needs. And in the process of doing all that I'm going to get that 'remote-shell' command stuff working at least as a minimal prototype. Might need to ping the network gurus for help after the proto is working to finish up the design and make it truly kick ass :-) Anyways... email for any reason. Aighty? Cheers, --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Sep 13, 2007, at 3:17 AM, Jason Dillon wrote: I'm converting all of the assemblies tonight, should be done in another hour or so. But, currently server/trunk is not building due to: snip [INFO] Compiling 18 source files to /Users/jason/ws/geronimo/server/ modules/geronimo-openejb/target/classes [INFO] -- -- [ERROR] BUILD FAILURE [INFO] -- -- [INFO] Compilation failure /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.TransactionServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.SecurityServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo /snip So, I can't verify that everything is super happy... I've deployed a new version of OpenEJB 3.0 snapshots. So, verify away... :-) You may need to delete old versions of OpenEJB snapshots from your maven repo (depending on when you built last...). --kevan
Re: New GShell-based Geronimo Server launcher now in server/trunk
Aighty, thanks Kevan, she builds for me now. Going to run through some tests now to see if I've broken anything... --jason On Sep 13, 2007, at 10:27 AM, Kevan Miller wrote: On Sep 13, 2007, at 3:17 AM, Jason Dillon wrote: I'm converting all of the assemblies tonight, should be done in another hour or so. But, currently server/trunk is not building due to: snip [INFO] Compiling 18 source files to /Users/jason/ws/geronimo/ server/modules/geronimo-openejb/target/classes [INFO] - --- [ERROR] BUILD FAILURE [INFO] - --- [INFO] Compilation failure /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[131,30] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.TransactionServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[139,27] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.SecurityServiceInfo /Users/jason/ws/geronimo/server/modules/geronimo-openejb/src/main/ java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java:[145,24] cannot find symbol symbol : variable service location: class org.apache.openejb.assembler.classic.ProxyFactoryInfo /snip So, I can't verify that everything is super happy... I've deployed a new version of OpenEJB 3.0 snapshots. So, verify away... :-) You may need to delete old versions of OpenEJB snapshots from your maven repo (depending on when you built last...). --kevan
Re: New GShell-based Geronimo Server launcher now in server/trunk
This is really cool stuff, I'm pretty blown away. I'm convinced that a significant percentage of app server administrators prefer a power scripting interface over a fancy UI, so now Geronimo can offer both. I seem to recall some discussion about supporting multiple scripting languages.. but I can't find anything in the dev archives though so maybe I am imagining that? Either way, I think groovy is certainly adequate. Best wishes, Paul On Sep 8, 2007, at 3:40 PM, Jason Dillon wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/ gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447
Re: New GShell-based Geronimo Server launcher now in server/trunk
Aighty, well... I've done some long awaited re-factoring, and while its still not _perfect_ its a whole lot better now IMO I think from a framework perspective that its probably mature enough to take on the task of being the server bootloader. I'm going to continue to refactor the guts of GShell over time, of course... but I think that what is there now is highly usable for a simple platform independent launcher, as well as for porting over the other cli bits we have. I've done a lot of work in the past week, incase you didn't see the storm of scm messages... pulled out pico, plopped in plexus, pulled out commons-logging and commons-lang, which are suck and boated (in that order). I've gotten the basic framework and supported classes to use GShell down to ~ 1mb (a wee bit under)... though when I started to add the layout.xml abstraction stuff, I had to pull in xstream which bloated her back up to ~1.4m. I may eventually fix that... or not, cause xstream is s very handy for xml - object stuff. I've fallen in love with annotations... they are *ucking great. They work really well for handling the cli option and argument muck which most every command needs to do. And striping out the insano-sucking commons-cli really simplified command implementations dramatically IMO. Anyways... I've make a heck of a lot of progress on cleaning up the GShell framework... and more is to come I'm sure... But for now, I think its probably ready for use primetime as the Geronimo Server's bootloader. I think this provides a some significant value... 1) Platform scripts become consistent and relatively simple, easy to maintain 2) Everyone will now have a consist way of launching the server, even if you like a .sh, .bat, or java -jar, then end process that is launched will be the same for everyone. 3) Opens up the door for some really nice and fancy fancy management muck (like restarting the server from the web console, or cloning a server instance or backing up a server instance...) 4) Lays the ground work for future features, like cluster management, remote administration and scripting... * * * So, I think its time to decide... are we a go or no go for GShell as the core CLI for Geronimo thingys and even more important, are we go or no go for using GShell to boot up the server process? --jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447 restart-server now Geronimo server shutting down... Geronimo server shutdown. Geronimo server starting... ... Geronimo server started in ... Since GShell manages the processes its really easy to perform a full restart of a Server w/o needing magical platform scripting muck. And it will just work the same on each platform too. Once we have clustering, then we can do the same kinda thing for an entire cluster of nodes... someserver:9447 restart-cluster now
Re: New GShell-based Geronimo Server launcher now in server/trunk
Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot/ gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447 restart-server now Geronimo server shutting down... Geronimo server shutdown. Geronimo server starting... ... Geronimo server started in ... Since GShell manages the processes its really easy to perform a full restart of a Server w/o needing magical platform scripting muck. And it will just work the same on each platform too. Once we
Re: New GShell-based Geronimo Server launcher now in server/trunk
Ya, should be simple enough... though I don't want to keep maintaining these extra assemblies, I'd like to just convert all of the assemblies to use this stuff... But if it helps ya out, I can make a geronimo-tomcat6-javaee5-gshell... --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../ lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/ gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver listening on 9443 (over ssl of course). Or how about you want to reboot a server remotely? someserver:9447 restart-server now Geronimo server shutting down...
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Sep 8, 2007, at 1:46 PM, Jason Dillon wrote: Ya, should be simple enough... though I don't want to keep maintaining these extra assemblies, I'd like to just convert all of the assemblies to use this stuff... I was convinced this was the way to go after trying the first jetty- gshell a couple weeks ago. thanks david jencks But if it helps ya out, I can make a geronimo-tomcat6-javaee5- gshell... --jason On Sep 8, 2007, at 12:52 PM, Jeff Genender wrote: Is this working for the Tomcat assembly? If not...can it soon? Thanks, Jeff Sent from my iPhone On Sep 8, 2007, at 1:40 PM, Jason Dillon [EMAIL PROTECTED] wrote: A little bit more insight into what I'm thinking of doing... since some of you can't read minds to well :-P I'd like to convert all of the assemblies to basically look like what the assemblies/geronimo-jetty6-javaee5-gshell produces. And then I'd like to start converting the other cli bits to gshell command impls, like: deployer, client and shutdown. And then (maybe around the same time or before the above), I'd like to adapt the gshell of target jvm bits to load jars from the repository, instead of using the lib/* bits. A little background for those who haven't looked at assemblies/ geronimo-jetty6-javaee5-gshell and what it produces from a lib/* perspective. Right now I've set up the assembly to produce: geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/boot geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/endorsed geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/gshell Where the bits in lib/* and lib/endorsed/* are the same as they were before. The bits in lib/boot/* and lib/gshell/* are specific to gshell. And normally a gshell installation would have everything I put into lib/gshell/* into lib/*, but I moved them to a sub dir for now... since the bin/*.jar's load jars from the ../lib/* dirs. The lib/boot/* stuff is the very minimal gshell bootstrap classes, which setup up the other happiness... and let you do things like: java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar And that will give you a nice shell... or java -jar ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/lib/ boot/gshell-bootstrap.jar start-server That will launch the G server process using all of the right - Djava.ext.dirs and whatever properties that we currently have hacked into platform scripts. Anyways, so the idea is to move all of the bits which are current in the lib/* into the repository, and then configure the gshell command impl to load put the correct dependency artifacts onto the classpath of the target jvm that is booted up. This will augment the existing kernel bootstrap from repo stuff, putting evertying except what is needed from gshell into the repository... And really, what I'd like to eventually get to is having the bootstrap from the repository... so that everything except for what is now it lib/boot/* and lib/endorsed/* can live in the repository like happy little communistic jars should be :-P * * * And then there are longer term things for GShell... Remote administration (via, telnet, ssh, or custom ssl protocol... last is most likely to actually happen soonish) Process management, which is great for clusters, or staging - production management. A full suite of command-line tools which can manage the configuration of a server... easily. So, for example, lets say you've got a configuration that is working really well for you... but you want to play with something new... So you might: ./bin/gsh backup-configuration before-mucking ./bin/gsh start-server And then go and change a whole bunch of stuff... and it doesn't work... yikes... so rollback... ./bin/gsh backup-configuration hosed-server ./bin/gsh restore-configuration before-mucking ./bin/gsh start-server And then maybe you want to play with the hosed-server configuration again... ./bin/gsh start-server --configuration hosed-server Of course, all of these could have been run from a single ./bin/ gsh, but just for clarity, you can run them one off too. Maybe list or mange the configurations ./bin/gsh list-configurations ./bin/gsh remove-configuration some-unwanted-config ./bin/gsh copy-configuration default some-new-config The sky is the limit really... for what kind of management we can do... Lets say you wanted to do the above on a remote node? ./bin/gsh remote-shell someserver:9443 Connecting to someserver:9447... Connected username: system password: (remember this is all jline, so we can mask passwords like one woudl expect) someserver:9447 list-configurations someserver:9447 remove-configuration some-unwanted-config someserver:9447 copy-configuration default some-new-config So, all of these operations would happen on the node named someserver
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Aug 27, 2007, at 8:28 PM, Prasad Kashyap wrote: I wanted to see how much Jason really really luvs Windows. So I began trying GShell on that OS :-) First, I was surprised it even had batch files to support Windows users. Thanx Jason. You really have gone out of your way :-)... Just kidding ! gsh.bat had a small typo. svn commit: r570296 fixes that. Next, in the interactive mode, I tried start-server help. It threw the following error start-server help 23:02:42,030 ERROR [InteractiveConsole] Error java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:124) I'll try to debug this tomorrow morning. However, I believe GShell will be of great use/help when we want to build a stackable server starting from a bare-bones framework that won't even have a console. For this we'll need plugin install capabilities in the GShell. Go Jason, Go ! Whether you like it or not, there's a sizeable number of our users who will be on Windows. And whether I like it or not, I or somebody will have to try our popular features on that hated OS :-( Ya, I am aware of the very, very, very sad and unfortunate fact... those poor users. Anyways, GShell should help us build more portable fluff for them, since we can code the platform specifics directly in Java. I'm not sure what the above exception is from, I'll fire up a build on my windows system and see what it pukes up. --jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
Well, I'm not sure why you are seeing that evil NCDFE still... though I did find a wee bug in the --help/-h processing for the start-server command. Basically what you tried is not a valid option to the command, ie start-server help is a syntax error. Instead you probably wanted to say start-server --help. --jason On Aug 27, 2007, at 8:28 PM, Prasad Kashyap wrote: I wanted to see how much Jason really really luvs Windows. So I began trying GShell on that OS :-) First, I was surprised it even had batch files to support Windows users. Thanx Jason. You really have gone out of your way :-)... Just kidding ! gsh.bat had a small typo. svn commit: r570296 fixes that. Next, in the interactive mode, I tried start-server help. It threw the following error start-server help 23:02:42,030 ERROR [InteractiveConsole] Error java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:124) I'll try to debug this tomorrow morning. However, I believe GShell will be of great use/help when we want to build a stackable server starting from a bare-bones framework that won't even have a console. For this we'll need plugin install capabilities in the GShell. Go Jason, Go ! Whether you like it or not, there's a sizeable number of our users who will be on Windows. And whether I like it or not, I or somebody will have to try our popular features on that hated OS :-( Cheers Prasad On 8/21/07, Jason Dillon [EMAIL PROTECTED] wrote: Hiya folks, I finally got around to finishing up my POC of using GShell to launch the Geronimo Server and I have committed the bits that make it work to server/trunk. The new module which contains the GShell command implementation (and support) classes is: modules/geronimo-commands And a new assembly which has the GShell bits all in place for folks to test with is: assemblies/geronimo-jetty6-javaee5-gshell The assembly is not hooked up by default, but the code module is. So, to test it out, you need to do something like: svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server cd server mvn assemblies/geronimo-jetty6-javaee5-gshell mvn Then unzip the assembly: unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip And then finally try it out. First lets get the basic GShell command- line help: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help This should spit out something like: snip _ _ _ / ___/ ___|| |__ ___| | | | | _\___ \| '_ \ / _ \ | | | |_| |___) | | | | __/ | | \|/|_| |_|\___|_|_| GShell -- Geronimo command-line shell usage: gsh [options] command [args] -n,--non-interactiveRun in non-interactive mode -D,--define name=valueDefine a system property -V,--versionDisplay GShell version -c,--commands string Read commands from string -debug,--debug Enable DEBUG logging output -h,--help Display this help message -i,--interactiveRun in interactive mode -quiet,--quiet Limit logging output to ERROR -verbose,--verbose Enable INFO logging output /snip Then lets run the interactive-shell: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh This should leave you at a very plain prompt at the moment: snip _ /snip At this point you can type something like this to list all of the known commands: snip help commands /snip Which should spit back: snip Available commands (and aliases): start-server ( start ) set exit ( quit, bye ) unset source help /snip The command that I added is called 'start-server', with an alias of 'start'. This is basically an augmented and enhanced version of what the geronimo:start-server goal does in the geronimo-maven-plugin. To see its options run this: snip start-server --help /snip And it says: snip start-server -- Starts a new Geronimo server instance usage: start-server [options] -A,--javaagent jar Use a specific Java Agent, set to 'none' to disable -D,--property name=valueSet a system property -H,--home dir Use a specific Geronimo home directory -J,--javaopt option Set a JVM flag -b,--background Run the server process in the background. -h,--help Display this help message -j,--jvm dirUse a specific Java Virtual Machine for server process -l,--logfile file Capture console output to file -m,--module nameStart up a specific module by name. -q,--quietSuppress informative and warning messages
Re: New GShell-based Geronimo Server launcher now in server/trunk
Oh man,
Gshell is looking to be pretty sweet, awesome work Jason.
One thing that would definitely be cool is implementing SSH into it, and I
did notice there's already a Jira for that, I'm sure I can brainstorm up a
few other additions given time... want a little help on the side? =)
On 8/21/07, Jason Dillon [EMAIL PROTECTED] wrote:
Hiya folks, I finally got around to finishing up my POC of using
GShell to launch the Geronimo Server and I have committed the bits
that make it work to server/trunk. The new module which contains the
GShell command implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for folks
to test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So, to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell command-
line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin. To
see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual
Machine for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the server
process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for --veryverbose ;-)
And then give it a whirl and try to start the server up from the shell:
snip
start-server
/snip
or if you prefer more output:
snip
start-server -v
/snip
And so on...
This will actually create a newly forked JVM to run the server in,
and will eventually have a robust node manager thingy, but I've not
done that yet ;-)
The platform scripts are now super simple!!! All of the logic is now
in the command implementation. And eventually we can probably have
the geronimo-maven-plugin just invoke the command so that
*everything* uses the exact same method for launching the server
process.
* * *
As requested by Jeff, I added support to read in some scripts to
augment the launching of the server... so that plugins can add
properties and such easily. Right now this is the directory which is
inspected for scripts:
etc/rc.d
And currently the scripts need to be named like this:
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Aug 23, 2007, at 8:40 AM, Joe Bohn wrote: Jason, I finally got around to looking at this. It's really cool! :-) This is a great way to address the environment and java opt issues in a more dynamic way to plugins to potentially exploit. In addition to some of the items David mentioned it would also be great to have some more query capabilities both in gsh and the start-server script. For example; the ability to list all environment variables, list system or geronimo properties set, list javaopts, list of all scripts to be run prior to the starting server, etc... Sure, thats all uber simple to add. One curious thing I noticed was that it seemed to drag a bit when I terminated geronimo from the console. It might have nothing to do with gsh but it seemed to take a long time before the gsh showed the server finally terminated ... just fyi and fwiw ... may be nothing to do with gsh. No, its not anything to do with gsh directly, its just that you aren't seeing the messages on the console when the server shuts down. I'm not really sure how to capture that stuff actually, same problem happens with the geronimo:start-sever goal. I did however add a message to the console when a shutdown is detected to let the user know what was going on. --jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
So, is this something that I should pursue? I've seen a few positive
comments on this functionality, nothing negative...
Should I invest more time in making this feature complete and set it
up as the default system for launching the server?
--jason
On Aug 21, 2007, at 3:05 PM, Jeff Genender wrote:
Oh man this is sweet...
I'd *really* like to see this in 2.0.2...
Jeff
Jason Dillon wrote:
Hiya folks, I finally got around to finishing up my POC of using
GShell
to launch the Geronimo Server and I have committed the bits that
make it
work to server/trunk. The new module which contains the GShell
command
implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for
folks to
test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So,
to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell
command-line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known
commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin. To
see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual Machine
for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the server
process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for --veryverbose ;-)
And then give it a whirl and try to start the server up from the
shell:
snip
start-server
/snip
or if you prefer more output:
snip
start-server -v
/snip
And so on...
This will actually create a newly forked JVM to run the server in,
and
will eventually have a robust node manager thingy, but I've not done
that yet ;-)
The platform scripts are now super simple!!! All of the logic is
now in
the command implementation. And eventually we can probably have the
geronimo-maven-plugin just invoke the command so that *everything*
uses
the exact same method for launching the server process.
* * *
As requested by Jeff, I added support to read in some scripts to
augment
the launching of the server... so that plugins can add properties and
such easily. Right now this is the directory which is inspected for
scripts:
etc/rc.d
And currently the scripts need to be named like this:
command-name,custom.groovy
I've created a default one for
Re: New GShell-based Geronimo Server launcher now in server/trunk
Jason Dillon wrote: So, is this something that I should pursue? I've seen a few positive comments on this functionality, nothing negative... Should I invest more time in making this feature complete and set it up as the default system for launching the server? Yes! --jason On Aug 21, 2007, at 3:05 PM, Jeff Genender wrote: Oh man this is sweet... I'd *really* like to see this in 2.0.2... Jeff Jason Dillon wrote: Hiya folks, I finally got around to finishing up my POC of using GShell to launch the Geronimo Server and I have committed the bits that make it work to server/trunk. The new module which contains the GShell command implementation (and support) classes is: modules/geronimo-commands And a new assembly which has the GShell bits all in place for folks to test with is: assemblies/geronimo-jetty6-javaee5-gshell The assembly is not hooked up by default, but the code module is. So, to test it out, you need to do something like: svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server cd server mvn assemblies/geronimo-jetty6-javaee5-gshell mvn Then unzip the assembly: unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip And then finally try it out. First lets get the basic GShell command-line help: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help This should spit out something like: snip _ _ _ / ___/ ___|| |__ ___| | | | | _\___ \| '_ \ / _ \ | | | |_| |___) | | | | __/ | | \|/|_| |_|\___|_|_| GShell -- Geronimo command-line shell usage: gsh [options] command [args] -n,--non-interactiveRun in non-interactive mode -D,--define name=valueDefine a system property -V,--versionDisplay GShell version -c,--commands string Read commands from string -debug,--debug Enable DEBUG logging output -h,--help Display this help message -i,--interactiveRun in interactive mode -quiet,--quiet Limit logging output to ERROR -verbose,--verbose Enable INFO logging output /snip Then lets run the interactive-shell: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh This should leave you at a very plain prompt at the moment: snip _ /snip At this point you can type something like this to list all of the known commands: snip help commands /snip Which should spit back: snip Available commands (and aliases): start-server ( start ) set exit ( quit, bye ) unset source help /snip The command that I added is called 'start-server', with an alias of 'start'. This is basically an augmented and enhanced version of what the geronimo:start-server goal does in the geronimo-maven-plugin. To see its options run this: snip start-server --help /snip And it says: snip start-server -- Starts a new Geronimo server instance usage: start-server [options] -A,--javaagent jar Use a specific Java Agent, set to 'none' to disable -D,--property name=valueSet a system property -H,--home dir Use a specific Geronimo home directory -J,--javaopt option Set a JVM flag -b,--background Run the server process in the background. -h,--help Display this help message -j,--jvm dirUse a specific Java Virtual Machine for server process -l,--logfile file Capture console output to file -m,--module nameStart up a specific module by name. -q,--quietSuppress informative and warning messages -t,--timeout secondsSpecify the timeout for the server process in seconds -v,--verbose Enable verbose output; specify multipule times to increase verbosity. /snip NOTE: Use -vv for --veryverbose ;-) And then give it a whirl and try to start the server up from the shell: snip start-server /snip or if you prefer more output: snip start-server -v /snip And so on... This will actually create a newly forked JVM to run the server in, and will eventually have a robust node manager thingy, but I've not done that yet ;-) The platform scripts are now super simple!!! All of the logic is now in the command implementation. And eventually we can probably have the geronimo-maven-plugin just invoke the command so that *everything* uses the exact same method for launching the server process. * * * As requested by Jeff, I added support to read in some scripts to augment the launching of the server... so that plugins can add properties and such easily. Right now this is the directory which is inspected for scripts: etc/rc.d And
Re: New GShell-based Geronimo Server launcher now in server/trunk
I wanted to see how much Jason really really luvs Windows. So I
began trying GShell on that OS :-)
First, I was surprised it even had batch files to support Windows
users. Thanx Jason. You really have gone out of your way :-)... Just
kidding !
gsh.bat had a small typo. svn commit: r570296 fixes that.
Next, in the interactive mode, I tried start-server help. It threw
the following error
start-server help
23:02:42,030 ERROR [InteractiveConsole] Error
java.lang.NoClassDefFoundError: groovy/lang/GroovyObject
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
I'll try to debug this tomorrow morning. However, I believe GShell
will be of great use/help when we want to build a stackable server
starting from a bare-bones framework that won't even have a console.
For this we'll need plugin install capabilities in the GShell.
Go Jason, Go !
Whether you like it or not, there's a sizeable number of our users who
will be on Windows. And whether I like it or not, I or somebody will
have to try our popular features on that hated OS :-(
Cheers
Prasad
On 8/21/07, Jason Dillon [EMAIL PROTECTED] wrote:
Hiya folks, I finally got around to finishing up my POC of using
GShell to launch the Geronimo Server and I have committed the bits
that make it work to server/trunk. The new module which contains the
GShell command implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for folks
to test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So, to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell command-
line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin. To
see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual
Machine for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the server
process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for
Re: New GShell-based Geronimo Server launcher now in server/trunk
Jason,
I finally got around to looking at this. It's really cool!
This is a great way to address the environment and java opt issues in a
more dynamic way to plugins to potentially exploit.
In addition to some of the items David mentioned it would also be great
to have some more query capabilities both in gsh and the start-server
script. For example; the ability to list all environment variables,
list system or geronimo properties set, list javaopts, list of all
scripts to be run prior to the starting server, etc...
One curious thing I noticed was that it seemed to drag a bit when I
terminated geronimo from the console. It might have nothing to do with
gsh but it seemed to take a long time before the gsh showed the server
finally terminated ... just fyi and fwiw ... may be nothing to do with gsh.
Great work Jason!
Joe
Jason Dillon wrote:
Hiya folks, I finally got around to finishing up my POC of using GShell
to launch the Geronimo Server and I have committed the bits that make it
work to server/trunk. The new module which contains the GShell command
implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for folks to
test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is. So,
to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell
command-line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the known
commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin. To
see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual Machine
for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning messages
-t,--timeout secondsSpecify the timeout for the server
process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for --veryverbose ;-)
And then give it a whirl and try to start the server up from the shell:
snip
start-server
/snip
or if you prefer more output:
snip
start-server -v
/snip
And so on...
This will actually create a newly forked JVM to run the server in, and
will eventually have a robust node manager thingy, but I've not done
that yet ;-)
The platform scripts are now super simple!!! All of the logic is now in
the command implementation. And eventually we can probably have the
geronimo-maven-plugin just invoke the
Re: New GShell-based Geronimo Server launcher now in server/trunk
I played around with this a little bit and really like it.
Some things I'd like to see soon:
- stop the server w/o stopping the shell
- run app clients
- run the deployers (including plugin deployer). esp. for plugins it
might be nice to be able to set the repo to look at as an env var
in gshell and have partial listings or artifact name completion or
something like that.
- easy way to debug, setting the port and suspend, perhaps again with
'env vars
- easy way to set e.g. portOffet. IIUC you can set them with -
Dorg.apache.geronimo.configuration.portOffset=1 but having a way of
leaving out the prefix would be handy maybe -GportOffset=1
For some reason I want to be able to type commands into the console
where I'm looking at the server console output :-) This might end up
being confusing or unpleasant but maybe an escape character could
switch to a command mode from viewing the console output mode. Or
maybe another way to think of this is to switch back and forth
between the server being in the background.
I'm looking forward to this developing more features :-)
many thanks!
david jencks
On Aug 21, 2007, at 9:12 PM, Jason Dillon wrote:
FYI, for those that still like to use java -jar... you can still do
that, with:
java -jar lib/boot/gshell-bootstrap.jar start-server
And this will actually setup all the right java.ext.dirs and such
too ;-)
--jason
On Aug 21, 2007, at 2:55 PM, Jason Dillon wrote:
Hiya folks, I finally got around to finishing up my POC of using
GShell to launch the Geronimo Server and I have committed the bits
that make it work to server/trunk. The new module which contains
the GShell command implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for
folks to test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So, to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell
command-line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias
of 'start'. This is basically an augmented and enhanced version
of what the geronimo:start-server goal does in the geronimo-maven-
plugin. To see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set
to 'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual
Machine for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the
server process in
seconds
-v,--verbose Enable verbose output; specify
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Aug 21, 2007, at 11:40 PM, David Jencks wrote: I played around with this a little bit and really like it. Yay! Thanks for taking a look David! Some things I'd like to see soon: - stop the server w/o stopping the shell - run app clients - run the deployers (including plugin deployer). esp. for plugins it might be nice to be able to set the repo to look at as an env var in gshell and have partial listings or artifact name completion or something like that. I plan to make GShell commands for all of the above soon, was just waiting for folks to take a look at the start-server bits I added as a POC and get feedback before I dive into all the other commands. Though you can still run the existing scripts to use those tools, but ya I do plan on adding them as GShell commands soon ;-) - easy way to debug, setting the port and suspend, perhaps again with 'env vars Yup, we can add any flags to 'start-server' which help make life easier... probably need to get those bits from the geronimo.sh script ported over too, 'jpda, start, stop, run, etc'. You can current do stuff like this in the shell: set debug_flags=foo And then commands have that context passed in... but so far, except for the 'set' and 'unset' commands no commands use that context yet. There is also a evil bug in the current parser that freaks out on quotes... which I hope to get fixed soon. - easy way to set e.g. portOffet. IIUC you can set them with - Dorg.apache.geronimo.configuration.portOffset=1 but having a way of leaving out the prefix would be handy maybe -GportOffset=1 I've added a -G flag... so -Gfoo=bar is the same as - Dorg.apache.geronimo.foo=bar. We can sort out all of the nice short- hand flags over time... ;-) But keep the ideas coming for sure... cause I'm not sure how folks actually use this stuff ;-) For some reason I want to be able to type commands into the console where I'm looking at the server console output :-) This might end up being confusing or unpleasant but maybe an escape character could switch to a command mode from viewing the console output mode. Or maybe another way to think of this is to switch back and forth between the server being in the background. Yup, right now... I think... you can 'start-server --background' and it will wait for the server to boot, then return you to a shell and server output will still be put on console, unless you used 'start- server --logfile /foo/bar' or something. But I eventually want to get this syntax working for the same thing: start-server But that requires more parser hacking... so, its a feature planned on, but pending someone to help me with the grammar and ast mucko ;-) I'm looking forward to this developing more features :-) Yay! I'm starting to become more interested in making GShell rule the world again too ;-) Cheers, --jason
New GShell-based Geronimo Server launcher now in server/trunk
Hiya folks, I finally got around to finishing up my POC of using
GShell to launch the Geronimo Server and I have committed the bits
that make it work to server/trunk. The new module which contains the
GShell command implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for folks
to test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So, to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell command-
line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin. To
see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual
Machine for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the server
process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for --veryverbose ;-)
And then give it a whirl and try to start the server up from the shell:
snip
start-server
/snip
or if you prefer more output:
snip
start-server -v
/snip
And so on...
This will actually create a newly forked JVM to run the server in,
and will eventually have a robust node manager thingy, but I've not
done that yet ;-)
The platform scripts are now super simple!!! All of the logic is now
in the command implementation. And eventually we can probably have
the geronimo-maven-plugin just invoke the command so that
*everything* uses the exact same method for launching the server
process.
* * *
As requested by Jeff, I added support to read in some scripts to
augment the launching of the server... so that plugins can add
properties and such easily. Right now this is the directory which is
inspected for scripts:
etc/rc.d
And currently the scripts need to be named like this:
command-name,custom.groovy
I've created a default one for you to look at:
etc/rc.d/start-server,default.groovy
Which simply sets the max heap size to 512m:
snip
command.javaFlags '-Xmx512m'
/snip
When running the start-server command (or its aliases) all of the etc/
rc.d/start-server,*.groovy scripts are run (if any) before the
process is launched to allow the command.properties,
command.javaFlags and other bits to be
Re: New GShell-based Geronimo Server launcher now in server/trunk
Oh man this is sweet... I'd *really* like to see this in 2.0.2... Jeff Jason Dillon wrote: Hiya folks, I finally got around to finishing up my POC of using GShell to launch the Geronimo Server and I have committed the bits that make it work to server/trunk. The new module which contains the GShell command implementation (and support) classes is: modules/geronimo-commands And a new assembly which has the GShell bits all in place for folks to test with is: assemblies/geronimo-jetty6-javaee5-gshell The assembly is not hooked up by default, but the code module is. So, to test it out, you need to do something like: svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server cd server mvn assemblies/geronimo-jetty6-javaee5-gshell mvn Then unzip the assembly: unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip And then finally try it out. First lets get the basic GShell command-line help: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help This should spit out something like: snip _ _ _ / ___/ ___|| |__ ___| | | | | _\___ \| '_ \ / _ \ | | | |_| |___) | | | | __/ | | \|/|_| |_|\___|_|_| GShell -- Geronimo command-line shell usage: gsh [options] command [args] -n,--non-interactiveRun in non-interactive mode -D,--define name=valueDefine a system property -V,--versionDisplay GShell version -c,--commands string Read commands from string -debug,--debug Enable DEBUG logging output -h,--help Display this help message -i,--interactiveRun in interactive mode -quiet,--quiet Limit logging output to ERROR -verbose,--verbose Enable INFO logging output /snip Then lets run the interactive-shell: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh This should leave you at a very plain prompt at the moment: snip _ /snip At this point you can type something like this to list all of the known commands: snip help commands /snip Which should spit back: snip Available commands (and aliases): start-server ( start ) set exit ( quit, bye ) unset source help /snip The command that I added is called 'start-server', with an alias of 'start'. This is basically an augmented and enhanced version of what the geronimo:start-server goal does in the geronimo-maven-plugin. To see its options run this: snip start-server --help /snip And it says: snip start-server -- Starts a new Geronimo server instance usage: start-server [options] -A,--javaagent jar Use a specific Java Agent, set to 'none' to disable -D,--property name=valueSet a system property -H,--home dir Use a specific Geronimo home directory -J,--javaopt option Set a JVM flag -b,--background Run the server process in the background. -h,--help Display this help message -j,--jvm dirUse a specific Java Virtual Machine for server process -l,--logfile file Capture console output to file -m,--module nameStart up a specific module by name. -q,--quietSuppress informative and warning messages -t,--timeout secondsSpecify the timeout for the server process in seconds -v,--verbose Enable verbose output; specify multipule times to increase verbosity. /snip NOTE: Use -vv for --veryverbose ;-) And then give it a whirl and try to start the server up from the shell: snip start-server /snip or if you prefer more output: snip start-server -v /snip And so on... This will actually create a newly forked JVM to run the server in, and will eventually have a robust node manager thingy, but I've not done that yet ;-) The platform scripts are now super simple!!! All of the logic is now in the command implementation. And eventually we can probably have the geronimo-maven-plugin just invoke the command so that *everything* uses the exact same method for launching the server process. * * * As requested by Jeff, I added support to read in some scripts to augment the launching of the server... so that plugins can add properties and such easily. Right now this is the directory which is inspected for scripts: etc/rc.d And currently the scripts need to be named like this: command-name,custom.groovy I've created a default one for you to look at: etc/rc.d/start-server,default.groovy Which simply sets the max heap size to 512m: snip command.javaFlags '-Xmx512m' /snip When running the start-server command (or
Re: New GShell-based Geronimo Server launcher now in server/trunk
Its easy enough to get it working in 2.0.x... --jason -Original Message- From: Jeff Genender [EMAIL PROTECTED] Date: Tue, 21 Aug 2007 16:05:40 To:dev@geronimo.apache.org Subject: Re: New GShell-based Geronimo Server launcher now in server/trunk Oh man this is sweet... I'd *really* like to see this in 2.0.2... Jeff Jason Dillon wrote: Hiya folks, I finally got around to finishing up my POC of using GShell to launch the Geronimo Server and I have committed the bits that make it work to server/trunk. The new module which contains the GShell command implementation (and support) classes is: modules/geronimo-commands And a new assembly which has the GShell bits all in place for folks to test with is: assemblies/geronimo-jetty6-javaee5-gshell The assembly is not hooked up by default, but the code module is. So, to test it out, you need to do something like: svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server cd server mvn assemblies/geronimo-jetty6-javaee5-gshell mvn Then unzip the assembly: unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip And then finally try it out. First lets get the basic GShell command-line help: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help This should spit out something like: snip _ _ _ / ___/ ___|| |__ ___| | | | | _\___ \| '_ \ / _ \ | | | |_| |___) | | | | __/ | | \|/|_| |_|\___|_|_| GShell -- Geronimo command-line shell usage: gsh [options] command [args] -n,--non-interactiveRun in non-interactive mode -D,--define name=valueDefine a system property -V,--versionDisplay GShell version -c,--commands string Read commands from string -debug,--debug Enable DEBUG logging output -h,--help Display this help message -i,--interactiveRun in interactive mode -quiet,--quiet Limit logging output to ERROR -verbose,--verbose Enable INFO logging output /snip Then lets run the interactive-shell: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh This should leave you at a very plain prompt at the moment: snip _ /snip At this point you can type something like this to list all of the known commands: snip help commands /snip Which should spit back: snip Available commands (and aliases): start-server ( start ) set exit ( quit, bye ) unset source help /snip The command that I added is called 'start-server', with an alias of 'start'. This is basically an augmented and enhanced version of what the geronimo:start-server goal does in the geronimo-maven-plugin. To see its options run this: snip start-server --help /snip And it says: snip start-server -- Starts a new Geronimo server instance usage: start-server [options] -A,--javaagent jar Use a specific Java Agent, set to 'none' to disable -D,--property name=valueSet a system property -H,--home dir Use a specific Geronimo home directory -J,--javaopt option Set a JVM flag -b,--background Run the server process in the background. -h,--help Display this help message -j,--jvm dirUse a specific Java Virtual Machine for server process -l,--logfile file Capture console output to file -m,--module nameStart up a specific module by name. -q,--quietSuppress informative and warning messages -t,--timeout secondsSpecify the timeout for the server process in seconds -v,--verbose Enable verbose output; specify multipule times to increase verbosity. /snip NOTE: Use -vv for --veryverbose ;-) And then give it a whirl and try to start the server up from the shell: snip start-server /snip or if you prefer more output: snip start-server -v /snip And so on... This will actually create a newly forked JVM to run the server in, and will eventually have a robust node manager thingy, but I've not done that yet ;-) The platform scripts are now super simple!!! All of the logic is now in the command implementation. And eventually we can probably have the geronimo-maven-plugin just invoke the command so that *everything* uses the exact same method for launching the server process. * * * As requested by Jeff, I added support to read in some scripts to augment the launching of the server... so that plugins can add properties and such easily. Right now this is the directory which is inspected for scripts: etc/rc.d And currently the scripts need to be named like
Re: New GShell-based Geronimo Server launcher now in server/trunk
FYI, for those that still like to use java -jar... you can still do
that, with:
java -jar lib/boot/gshell-bootstrap.jar start-server
And this will actually setup all the right java.ext.dirs and such
too ;-)
--jason
On Aug 21, 2007, at 2:55 PM, Jason Dillon wrote:
Hiya folks, I finally got around to finishing up my POC of using
GShell to launch the Geronimo Server and I have committed the bits
that make it work to server/trunk. The new module which contains
the GShell command implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for folks
to test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So, to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell
command-line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of
what the geronimo:start-server goal does in the geronimo-maven-
plugin. To see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual
Machine for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the
server process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for --veryverbose ;-)
And then give it a whirl and try to start the server up from the
shell:
snip
start-server
/snip
or if you prefer more output:
snip
start-server -v
/snip
And so on...
This will actually create a newly forked JVM to run the server in,
and will eventually have a robust node manager thingy, but I've not
done that yet ;-)
The platform scripts are now super simple!!! All of the logic is
now in the command implementation. And eventually we can probably
have the geronimo-maven-plugin just invoke the command so that
*everything* uses the exact same method for launching the server
process.
* * *
As requested by Jeff, I added support to read in some scripts to
augment the launching of the server... so that plugins can add
properties and such easily. Right now this is the directory which
is inspected for scripts:
etc/rc.d
And currently the scripts need to be named like this:
command-name,custom.groovy
I've created a default one for you to look at:
etc/rc.d/start-server,default.groovy
Which simply sets the max heap size to
