4 ms·

"just leave a screen with slime and emacs running on your server" Another way to do it is just load the swank jar on your server (the server side of slime). In

by arohner 17y ago

"just leave a screen with slime and emacs running on your server" Another way to do it is just load the swank jar on your server (the server side of slime). In your server startup, include a call to (start-swank). Then you can connect via slime whenever you want using M-x slime-connect, and you don't need emacs + screen to stay running. I've only learned the JVM as part of learning clojure. What advantages would a .war provide?

sunkencity 17y ago
Advantages: Easy to get a server running: just install tomcat or jetty on your production machine, sftp the war file and it automatically deploys. Init.d scripts are tricky to write and get right, by using a tested script from a distro things tend to work out of the box. Monitoring -- easy to hook in some monitoring script that can reboot tomcat or jetty should the server stop responding. Techops generally know how to deploy a .war file -- I would not feel comfortable telling someone to learn lisp just to deploy a webapp. pretty interesting with swank -- need to look into that.
- arohner 17y ago
  The war file and swank shouldn't be mutually exclusive, I just haven't bothered with a .war because by default Compojure starts Jetty itself, and I didn't want to bother with compiling the .war and restarting the server to test changes. Once you get addicted to reloading code from your IDE, you don't want to go back. :-)
jacquesm 17y ago
> What advantages would a .war provide? Deployment. If you have a procedure in place that handles versions of the server side code using .war files then you can simply give the sysadmins a new war to deploy and that will be that. It's convenient because it is just a single file, if you want to roll back just move the old war file in to place, do 10 seconds of housekeeping and you're back up. Not that anybody ever had to revert to a previous version of their production code, of course. But in that hypothetical case... Another advantage would be if you've automated your deployment across a large number of servers using this method. Update the master, send the signal to 'fetch and deploy' to the rest of your servers and that's it.

by arohner 17y ago

sunkencity 17y ago

Advantages: Easy to get a server running: just install tomcat or jetty on your production machine, sftp the war file and it automatically deploys. Init.d scripts are tricky to write and get right, by using a tested script from a distro things tend to work out of the box. Monitoring -- easy to hook in some monitoring script that can reboot tomcat or jetty should the server stop responding. Techops generally know how to deploy a .war file -- I would not feel comfortable telling someone to learn lisp just to deploy a webapp. pretty interesting with swank -- need to look into that.

arohner 17y ago
The war file and swank shouldn't be mutually exclusive, I just haven't bothered with a .war because by default Compojure starts Jetty itself, and I didn't want to bother with compiling the .war and restarting the server to test changes. Once you get addicted to reloading code from your IDE, you don't want to go back. :-)

jacquesm 17y ago

> What advantages would a .war provide? Deployment. If you have a procedure in place that handles versions of the server side code using .war files then you can simply give the sysadmins a new war to deploy and that will be that. It's convenient because it is just a single file, if you want to roll back just move the old war file in to place, do 10 seconds of housekeeping and you're back up. Not that anybody ever had to revert to a previous version of their production code, of course. But in that hypothetical case... Another advantage would be if you've automated your deployment across a large number of servers using this method. Update the master, send the signal to 'fetch and deploy' to the rest of your servers and that's it.