most of the teams can skip this step<\/strong>. Meaning your production application is not using different file paths from your development paths. This is because you are storing uploaded files as blobs in the database. But sometimes databases are setup to store only the file path to the uploaded file rather than the complete file. If your database is configured like this then the file paths will be different on the development machine then on the production server. Below is technique to make it convenient to have different file paths.<\/p>\nThis is an example of the solution used to determine the photo upload location in the Mushroom Mapper app.<\/p>\n
A json file in the project (specifically, MushroomMapper\/web-app\/text\/photo_cfg.json) contains internal and external paths to use for the upload location, for both development and production environments:<\/p>\n
{\r\n \"production\": {\r\n \t\t \"server\": \"\/itss\/local\/home\/cittemp\/public_html\/photos\/\",\r\n \t \t\"client\": \"\/photos\/\"\r\n \t },\r\n \t\"development\": {\r\n \t\t\"server\": \"web-app\/images\/photos\/\",\r\n \t\t \"client\": \"\/MushroomMapper\/images\/photos\/\"\r\n \t }\r\n}\r\n<\/pre>\nThis file makes it easy to find and change the paths if necessary, without delving into the code.<\/p>\n
A function called initPhotos parses this file, and sets the current server and client variables depending on the current environment context. This function can be a method of a controller.\u00a0 In the case of mushroom mapper it is a method of the main controller, ObservationsController.groovy. The variables set by the function are servletContext.photos.server and servletContext.photos.client.<\/p>\n
void initPhotos() {\r\n def txt = servletContext.getResourceAsStream('text\/photo_cfg.json')\r\n def cfg = new JsonSlurper().parseText(txt.getText())\r\n if (Environment.current == Environment.PRODUCTION) \r\n servletContext.photos = cfg.production\r\n else servletContext.photos = cfg.development\r\n}\r\n<\/pre>\nThe \u2018servletContext\u2019 variable (which is the \u2018application\u2019 variable when used in a gsp) behaves as a map whose data persists across all requests and sessions, so this function only needs to be called once for the lifetime of the server. Therefore, the following line is at the start of each action\/method of the controller that uses these variables:<\/p>\n
if (servletContext.photos == null) initPhotos()\r\n<\/pre>\n\u2018photos.server\u2019 is the internal path to the photos directory, and should be used with Groovy File objects, etc. \u2018photos.client\u2019 is the external uri, and should be used in the html, javascript, etc.<\/p>\n
Naturally, the user running the server should have +rwx permissions on the directory in question.<\/p>\n
Package your application into a WAR<\/h1>\n
Packaging your application into a WAR<\/em> only requires that the WAR file is named properly and that it is built for the correct environment. The WAR should be built for the production environment before uploading it to the production server.<\/p>\nThe WAR is named in BuildConfig.groovy configuration file. In the BuildConfig.groovy, uncomment the war.file specification. It is near the top of the file, and edit it so that it looks like<\/p>\n
grails.project.war.file = \"target\/${appName}.war\"<\/pre>\nNote we do not want the version number included in the war file name. The WAR file name must match the project name or the web app will not deploy properly. You can edit the WAR file name if you want without hurting the contents.\u00a0 Once your have configured the WAR name properly, you’ll not have to do this again.<\/p>\n
To make the WAR file you run a grails command. You’ll need to do this step each time you want to deploy a new version of your web application. On your development machine, your home machine, make the war file in production environment mode. Production environment is the default for the “war” command but not for the “run-war” command. The command executed in your project directory is simply<\/p>\n
grails war<\/pre>\nThe build and compression will take several minutes. You will find the WAR file in your project\u2019s target\/ directory.<\/p>\n
Uploading the WAR to your Server and Insure it is running<\/h1>\n
Tomcat servers have a special directory called the appbase<\/em>. The WAR files are uploaded to the appbase directory and then tomcat will expand\/explode the WAR file in the directory. This deploys the web application. If there is already a WAR file with the same name then the old WAR file should be deleted before uploading the new WAR file. Tomcat will detect that the WAR file is deleted and delete the corresponding exploded web application. This is called undeploying. You must undeploy before redeploying.<\/p>\nBecause Tomcat is just a Java application, the machine running Tomcat can have multiple instances of Tomcat. In order that the Tomcat servers do not interfere with each other while serving pages, the different instances of the Tomcat server are configured to receive their request and send their responses through different port numbers. Recall\u00a0that while you were programming and testing your individual assignments you would point your browser to the URL<\/p>\n
http:\/\/localhost:8080\/cs4760progassign\/<\/pre>\n
\n- http: – represents the protocol, in this case hypertext transfer protocol<\/li>\n
- localhost \u2013 is the domain name for the server, in this case it means the current machine<\/li>\n
- 8080 \u2013 is the port number<\/li>\n<\/ul>\n
Each team in the class has their own instance of Tomcat to use for deployment. But each Tomcat will be listening and sending to a different port.<\/p>\n
Domain<\/h2>\n
The domain name for the machine with the tomcat instances is<\/p>\n
cshci-dev.mtu.edu<\/pre>\nAppBase<\/h2>\n
To deploy your\u00a0 WAR file you need to know the appbase for your tomcat instances. The appBase for the tomcat intstances for each teams are at<\/p>\n
\n- \/usr\/share\/tomcat_team1_201501\/webapps\/<\/li>\n
- \/usr\/share\/tomcat_team1_201501\/webapps\/<\/li>\n
- \/usr\/share\/tomcat_team3_201501\/webapps\/<\/li>\n
- \u2026<\/li>\n<\/ul>\n
In other words the directory for the different tomcat instances have the format that specifies the <team-number>, <year> and <semester>. Team number is the your team number in the course.<\/p>\n
tomcat_team<team-number>_<year><semester><\/pre>\nThe spring semester is <semester> = 01<\/p>\n
The year for 2015 is <year> = 2015. For the year 2016 it will be <year> = 2016, etc<\/p>\n
Each team has access only to their tomcat instance’s directories. If your explore your tomcat directories your should find the logs\/ directory.\u00a0 You may need to study the log files if you have errors after deploying. The log file that the errors will printed in are the catalina.***.log. A new log file is created each day. You\u00a0find most recent entry in the log file you scroll to the bottom of the log file.<\/p>\n
Port Numbers<\/h2>\n
As mention above each tomcat instance is configured to listen on a different point.<\/p>\n
\n- tomcat_team1 listens on port 8081<\/li>\n
- tomcat_team2 listens on port 8082<\/li>\n
- tomcat_team3 listens on port 8083<\/li>\n
- etc.<\/li>\n<\/ul>\n
The general form of the port numbers is<\/p>\n
808<team-number><\/pre>\nWhere <team-number> is your course team number.<\/p>\n
So, when you check your deployed web application, each team will have to use their own port number. Team 1 would point their browser to<\/p>\n
cshci-dev.mtu.edu:8081\/team-1-app-name<\/pre>\nwhere “team-1-app-name” is the app name that team one has for their web application. Team 2 would point their browser to<\/p>\n
cshci-dev.mtu.edu:8082\/team-2-app-name<\/pre>\netc.<\/p>\n
Special Note about the number of WAR files<\/h2>\n
JSP and especially Grails web applications use lots of memory. They can also have a memory leak if they are not redeployed properly. The tomcat instances for the class have enough memory for only one additional web applications besides the web application that comes standard with tomcat.<\/p>\n
In your appbase you’ll notice that there are already some directories which are web applications. They are:<\/p>\n
\n- default\/ – web app for bare domain<\/li>\n
- docs\/ – documents for how to use tomcat<\/li>\n
- examples\/ – example web applications<\/li>\n
- host-manager\/ – web app for managing domain name<\/li>\n
- manager\/ – web app for managing web apps<\/li>\n<\/ul>\n
Leave these web apps in your appBase. They do not consume much memory. You can access default, docs, and examples through your browser, and you should do so to check that your tomcat instances is running properly. You need a login to access the host-manager and the manager web app.<\/p>\n
Remember: ONLY add one more web app to your appBase, otherwise your tomcat might run out of memory and crash.<\/strong><\/p>\nUploading and Deploying<\/h1>\n
Using a SFTP client (WinSCP is a very good choice for Windows) login into the Tomcat machine. (See domain name above.) I highly recommend that you use RSA keys so that the client can auto log in during network distributions. If you are logging into the server from a machine not on MTU network then you need to use a virtual network (VPN) with mtu. Point a browser to<\/p>\n
vpn.mtu.edu<\/pre>\nLog in and then select “Standalone VPN client”. This will download “BIGIPEdgeClient.exe”. Run this executable file\u00a0in admin mode, and it will install the “BIG-IP Edge Client” to your apps. You run the client and click the “connect button.” A window will pop up asking for your username and password. After clicking the logon button, the VPN is created. You need to keep the app running while\u00a0use your\u00a0SFTP client to upload files to the server. If you do not have a VPN connection, you\u2019ll get an \u201cnetwork error\u201d and not be able to connect.<\/p>\n
In the SFTP client, navigate to the appBase. (See above for the appBase directory.)<\/p>\n
If you have previously deployed a WAR file for your\u00a0web app that you are currently deploying then it should still exist in the appBase alongside the exploded web app. The exploded wep app is a directory with the same name as the WAR file. Delete the old WAR in the appBase before uploading the new WAR.<\/strong><\/p>\nWait<\/strong>. Wait until Tomcat deletes the old exploded web app. If you do not wait then deployment will fail, and Tomcat will never explode the new WAR file.<\/p>\nWhen the old web app directory disappears, use your SFTP client to upload the new WAR file.<\/p>\n
Wait<\/strong>. Sometimes Tomcat takes several minute, up to 10 minutes, to see the new WAR file and explode it.<\/p>\nPoint your browser to the web app and inspect it. (See above for port number.)<\/p>\n
Something Goes Wrong<\/h1>\n
The above procedure can go wrong. Some typically difficulties are<\/p>\n
\n- The database lockfile is not deleted during redeployment<\/li>\n
- The exploded web application is not deleted during redeployment<\/li>\n
- Memory overflow locking or crashing the server<\/li>\n<\/ol>\n
You can determine the cause of your problems by inspecting the log files. In most cases stopping and starting tomcat will solve your problems. Sometimes you may need to delete the offending file or directory, e.g. the lockfile in the db\/ directory.<\/p>\n
You have access to a few commands that are normally run by the root user. These commands are called sudo commands and are proceed by “sudo.”<\/p>\n
There are four commands<\/p>\n
\n- start \u2013 to start tomcat<\/li>\n
- stop \u2013 to spot tomcat<\/li>\n
- restart \u2013 to stop and start<\/li>\n
- status \u2013 to check tomcat status<\/li>\n<\/ul>\n
The frequently used commands are stop and start. You first stop<\/em> tomcat then delete or inspect your files and finally you start<\/em> tomcat again. After starting tomcat you can make a fresh deployment.<\/p>\nTeam 1 would run commands<\/p>\n
sudo service tomcat_team1 stop\r\nsudo service tomcat_team1 start<\/pre>\nTeam 2 would use commands<\/p>\n
sudo service tomcat_team2 stop\r\nsudo service tomcat_team2 start<\/pre>\netc.<\/p>\n
Good luck<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":"by\u00a0Robert Pastel, Mark Woodford and Travis Forester Deploying a web app is fundamentally the operation of packaging the files in your development environment and uploading the package to the server, but there are details of the application that you will need to attend to so that your application runs properly on the server. In particular […]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":112,"menu_order":15,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1239","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/pages\/1239","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/comments?post=1239"}],"version-history":[{"count":20,"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/pages\/1239\/revisions"}],"predecessor-version":[{"id":1535,"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/pages\/1239\/revisions\/1535"}],"up":[{"embeddable":true,"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/pages\/112"}],"wp:attachment":[{"href":"https:\/\/cs4760.csl.mtu.edu\/2016\/wp-json\/wp\/v2\/media?parent=1239"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}