geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: New GShell-based Geronimo Server launcher now in server/trunk
Date Thu, 13 Sep 2007 07:17:10 GMT
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 <jason@planet57.com> 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)
>>
>> 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")
>> </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
>>>


Mime
View raw message