geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: New GShell-based Geronimo Server launcher now in server/trunk
Date Fri, 14 Sep 2007 14:53:09 GMT
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  

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/   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/
>>     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 <> 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 have clustering, then we can do the same kinda thing for  
>>>> an entire cluster of nodes...
>>>>    someserver:9447 > restart-cluster now
>>>>    Shutting down 2 nodes...
>>>>    <node1> Geronimo server shutting down...
>>>>    <node1>....
>>>>    <node2> Geronimo server shutting down...
>>>>    <node2>....
>>>>    <node1>Geronimo server shutdown.
>>>>    <node2>Geronimo server shutdown.
>>>>    Starting up 2 nodes...
>>>>    <node1>Geronimo server starting...
>>>>    <node1>..
>>>>    <node2>Geronimo server starting...
>>>>    <node2>..
>>>>    <node1>Geronimo server started in ...
>>>>    <node2>Geronimo server started in ...
>>>>    Started up 2 nodes.
>>>> And well, if you had some kinda script file which controlled say  
>>>> a logical grouping of nodes you could easily invoke that script  
>>>> (ya even on a remote system) and it will go and do it:
>>>> someserver:9447 > script -l groovy local:file://restart- 
>>>> universe.groovy qa-universe
>>>> The local: bit of the uri siginals the local URL handler to be  
>>>> used, which will cause the file://restart-universe.groovy to be  
>>>> loaded from the gsh instance where you are actually logged into  
>>>> (and ran the remote-shell gshell command) and will pipe its  
>>>> contents securely to the remote shell running on someserver:9447  
>>>> and pass it to the script command to execute.
>>>> The restart-universe.groovy might look something like this:
>>>> <snip>
>>>> import universe.Lookup
>>>> assert args.size == 1 : 'Missing universe name'
>>>> def universe = args[0]
>>>> // Look up a list of nodes (for now say they are basically  
>>>> hostname:port)
>>>> def nodes = Lookup.lookup(universe)
>>>>"Stopping universe ${universe}...")
>>>> nodes.each { host ->
>>>>    shell.execute("remove-shell $host stop-server")
>>>> }
>>>>"Universe ${universe} stopped")
>>>>"Starting universe ${universe}...")
>>>> nodes.each { host ->
>>>>    shell.execute("remove-shell $host start-server")
>>>> }
>>>>"Universe ${universe} started")
>>>> </snip>
>>>> Its kinda crude script, but I think you get the general point...
>>>> * * *
>>>> Anyways... I see... well, *HUGE* potential for this stuff...
>>>> And really, a lot of what I just described above isn't that far  
>>>> into fantasy, its all relatively easy to implement on top of  
>>>> GShell... as it is now (or really as it was a year+ ago when I  
>>>> wrote it).  Its really a matter of do others see the same  
>>>> value... and do others see the vision of using GShell as the  
>>>> core process launcher to allow things like "restart-server", or  
>>>> a "stop-server; copy-configuration default known-good; copy- 
>>>> configuration default testing; start-server", or that uber-fancy  
>>>> remote-shell muck.
>>>> So, I'm gonna give y'all a few days to grok (or try to) what  
>>>> I've just spit out... please ask questions or comment, as I like  
>>>> to know I'm not just talking to myself here.
>>>> And then maybe later next week, we might vote or come to some  
>>>> other consensus that this is the right direction for Geronimo,  
>>>> and well... then I'll make it become reality.
>>>> Aighty, and now I'll shut up :-P
>>>> --jason
>>>> On Sep 8, 2007, at 11:53 AM, Jason Dillon wrote:
>>>>> 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 soooo 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

View raw message