Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 27855 invoked from network); 13 Sep 2007 07:18:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Sep 2007 07:18:03 -0000 Received: (qmail 73284 invoked by uid 500); 13 Sep 2007 07:17:54 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 73026 invoked by uid 500); 13 Sep 2007 07:17:53 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 73015 invoked by uid 99); 13 Sep 2007 07:17:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Sep 2007 00:17:53 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jason.dillon@gmail.com designates 64.233.166.181 as permitted sender) Received: from [64.233.166.181] (HELO py-out-1112.google.com) (64.233.166.181) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Sep 2007 07:17:51 +0000 Received: by py-out-1112.google.com with SMTP id u52so1043296pyb for ; Thu, 13 Sep 2007 00:17:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; bh=98FGGR0GC5sqNTPQfRA2W3WKCVCMq+fW6UGagh73HUI=; b=TceVvIcd7ZFtRwEku7+48AQQLQ2PaEtLDZ71IykCwheAOYzP6okRQp6lYcURRsHOku2j1zEHxL8xiHpq0rE6dJZ5pnoQTTVxaDAKuKoV5I3l8MYlP3MaCyBhcNjkK1P/EPhuMcKV+RNYPx2bR3Dcp2w+Y6XMYlLgg04YSYuG9/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=A+orbxrTLEgMwpdT3OpdErSayo+eJDNNOqEHhy4aeO9+NHGmCOQTjXfLQCFnysRJpUMJN/vpPJWmie9d+wCpJLLp/QVwq7FjttDNTeVAnBZAs1NYuiHVsHFMOTgruwzbAYTvflXhG4PLIrGkrmsZgblNMwG0blUfPzIXAG7LGtc= Received: by 10.35.47.10 with SMTP id z10mr559843pyj.1189667849793; Thu, 13 Sep 2007 00:17:29 -0700 (PDT) Received: from ?10.0.1.100? ( [24.5.195.44]) by mx.google.com with ESMTPS id x48sm9015177pyg.2007.09.13.00.17.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Sep 2007 00:17:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <0CD8D757-4F02-48F3-B973-3FAF71DB6E34@savoirtech.com> References: <9C9D3424-9404-49DE-9F5A-5AF8B546E7B1@planet57.com> <4e8584bd0708280801n5ecfc45eucbd7c4fc752b1313@mail.gmail.com> <9461051E-BA4C-48B4-A81F-9CA8ACA97515@planet57.com> <0CD8D757-4F02-48F3-B973-3FAF71DB6E34@savoirtech.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Dillon Subject: Re: New GShell-based Geronimo Server launcher now in server/trunk Date: Thu, 13 Sep 2007 00:17:10 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) Sender: Jason Dillon X-Virus-Checked: Checked by ClamAV on apache.org 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: [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 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 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... >> Geronimo server shutting down... >> .... >> Geronimo server shutting down... >> .... >> Geronimo server shutdown. >> Geronimo server shutdown. >> Starting up 2 nodes... >> Geronimo server starting... >> .. >> Geronimo server starting... >> .. >> Geronimo server started in ... >> 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: >> >> >> 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) >> >> log.info("Stopping universe ${universe}...") >> nodes.each { host -> >> shell.execute("remove-shell $host stop-server") >> } >> log.info("Universe ${universe} stopped") >> >> log.info("Starting universe ${universe}...") >> nodes.each { host -> >> shell.execute("remove-shell $host start-server") >> } >> log.info("Universe ${universe} started") >> >> >> 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 >>>