I have a J2EE application that runs fine and is accessible to the internet. Some of our prospective customers would like to use it, but are unwilling to send their data over the internet.
As a workaround I've thought of providing them with the war file and letting them run it themselves.
The problem is: how do I make it trivial for them to update the application when I make a new version available? The more difficult it is, the less likely they are to buy in.
What's involved in writing an updater that fetches the latest war file from online and updates the web application? Is this even possible?
In the least they would need to redeploy the war file. Most application servers have an interface through which you can upload a new war file. I am in favor of doing this process manually i.e. you send them a war file and they can use the app server's admin page to deploy the new war. This way they explicitly know when they are updating the app. Also they control when they want to deploy a new version of the app and easily roll back to an older version.
I would recommend using Jetty as an embedded solution. I have used a few apps that that use the embeded functionality. It allows you to create a packaged distribution of your application that runs a servlet container out of the box.
Related
We build a GWT app (using gwt-maven-plugin) resulting in a .war file. Currently this .war file contains a file called hosted.html, which is used to run in development (née hosted) mode, when query parameter gwt.codesvr=... is specified.
Is there a security risk in having this the .war file in production, or is there another reason to make sure this file does not end up in the .war file?
If so, what is the simplest way to do so?
Thanks!
The GWT dev plugin requires the webserver+codeserver pair of host+port to be whitelisted so there's absolutely no security risk in deploying hosted.html. The benefit of deploying it is that you can debug your app with your production server.
Note: that necessary whitelisting is to prevent “XSS triggered by a simple query-string parameter”. An attacker could otherwise make you run a trusted GWT app with their own code server.
I created my first Java EE application (GWT + Hibernate). I want deploy my application on a Tomcat web server.
Could you give me a step by step tutorial?
You can start with Google App Engine + GWT tutorial if you are trying out deploying into Google Cloud - https://developers.google.com/web-toolkit/doc/latest/tutorial/appengine
This question is massive so I will try to bring it down to some steps that need some research to implement.
1st. You created an application using GWT and Hibernate. That means that you need some kind of a web server that understands java and can re-write the logic from java to javascript (for the clientside), and also connect to the database on the serverside and retrieve the data for the client.
This web server is tomcat so what you need is:
A computer that will work as a server. This could be your own machine or some server you can buy as a hosting solution. Buying something like this requires research and effort on your part and cannot be explained here.
A version of Tomcat or Resin or any other web server that understands java
A domain name. These can be bought from sites like this one, but there are some free ones around the web. They require static ips that is you cannot use them from a home line that changes ips. Even without a domain name you can host your site on the server but you need to access it by writing the machine's ip instead. - optional - A temporary solution would be to use some kind of dynamic dns service on your router.
After having set up tomcat (you might want to give port 80 to tomcat) and the server you can host your application by uploading the war file. You can make a war file from gwt by following the instructions here
To upload the war file you can use the tomcat manager interface, or you can connect to the server and place it manually in the folder used for the web applications.
I know that each step propably needs as much if not more explanation by I hope I cleared the area a little bit here.
I'm building a web app with Backbone.js (I'm not tied to Backbone yet though). I need a back-end framework only for persistence to a database via a RESTful API. However, I also need to able to deploy it as a 'desktop' app for off-line use, i.e. running a local server and launching a browser window, but I don't want users to have to start a server from the command line to run the application.
I can use SQLite as a database since it's only a single user application, it's just the framework that I'm stuck on. I have looked at the following:
Rails and Django: Default web servers are too flimsy, requires Ruby/Python and runs from the command line. I'm aware of the Bitnami stacks but at 99mb it's too big of a dependency and not exactly hidden from the user.
Sproutcore: Run from command line, also too bulky.
Pyjamas Desktop - Depends on MSHTML which I suspect limits my ability to use HTML5 features.
I'm leaning towards creating a Java app that starts a Scala/Lift server instance and opens a web browser, then sits in the system tray (kind of like WAMP). Is anyone familiar with a tool or framework built for user-friendly deployment as a standalone desktop app?
I do not know if PHP is an option for you? Then I would recommend phpdock.
web2py has a standalone deploy-to-desktop feature with no dependency on Python: http://web2py.com/books/default/chapter/29/14#How-to-distribute-your-applications-as-binaries
As Eydun said, phpdock is an option but it's commercially licensed .
I settled on using Java/Spring/H2/Hibernate/Jetty. I find that Jetty serves requests VERY quickly so the application looks real-time when launched in a browser. There is a tutorial on embedding the Jetty server here. I imagine it's quite trivial to build a GUI that launches the server and a browser.
Another Java option is to use the Play Framework, which may be more at home to those coming from a Django/Rails background. However, the documentation for "creating a standalone version of your application" for Play 2.0+ indicates that they have ditched using Java EE containers (Tomcat/Jetty) and WAR files in favor of running the JARs with the bundled copy of JBoss Netty, so it may take a bit of work to get it running the way you want it.
I would recommend the Play Framework approach if you're OK with using/learning Scala.
I want to remotely deploy my web app in Tomcat 7. I have added manager-gui, manager-text roles and added a user in conf/tomcat-users.xml. I checked this link out.
Deploy A New Application Remotely
Here they have mentioned that we must upload the war file as HTTP PUT request. How do I achieve this ? I know there are ways to remotely deploy using ANT and Maven. But they look slightly complex to me. Using <form> with method="put" did not work.
The HTML FORM will only support GET and POST. If you want to do this via a Web Interface I think JQuery is the simplest route. Taking the time to build it into your build and deploy process is probably the best solution though.
Where I work, we release bug fixes in to the system every night when we know our clients are not using the system.
Trying to take a step towards better service I'd like to deploy to IIS while the application is running.
A solution that comes to mind is to setup two different IIS applications and switch them over after deploy using a script. But I'm not going to try this out as I don't want any complications during our busy hours.
Does anyone have experience in this area of deployment?
Thanks
Regardless of whether you're using PHP, ASP, ASP.NET etc there is no native support for transactional deployment on IIS.
The simplest approach would be to have two physical folders and (optionally two web sites - one production, one test) on your web server, for example:
c:\websites\myapp\dep1
c:\websites\myapp\dep2
Initially your site would have its physical path pointing to c:\websites\myapp\dep1.
When you deploy your latest build you'd deploy into c:\websites\myapp\dep2. Once you're done just switch the physical path of the production site over to this folder. This means you still have the original site and can fall back to it if the new code fails for whatever reason.
The next time you do a deployment you'd deploy into c:\websites\myapp\dep1 and once you're done switch the production site to that folder.
You could optionally have a test site that points to the folder you're deploying to so you can make sure the site works before switching your production site over.
This could all be scripted.
Here's some related reading that may be of interest:
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?
Rob Conery also had an excellent blog post about the lack of a decent deployment story for ASP.NET application. You should take a trawl through the comments some of which are quite insightful:
ASP.NET Deployment Needs To Be Fixed
Getting Constructive On ASP.NET Deployment