I have a requirement where a jar deployed onto client side needs to be executed when a user click on a link on web page [it's an internal webpage]. To elaborate, I have a web page which provides details regarding multiple products, now when individual product owners click on their products then product specific jars need to be executed to open Swing UI.
I have done analysis on this and none of frameworks of libraries allow this due to security reasons from Run EXE from client side.
I suggested to perform this using applet but people are not keen on it.
EDIT:
Reason for excluding applet is that people are not keen on deploying jar on server. They want to deploy jar on client side and then execute it.
EDIT:
Reasons for not being keen on downloading jar are:
Jar is huge, in some cases around 100 mb.
If jar has to be deployed on to web server then a dependency gets added which products want to avoid because they do not want to sync up with release cycle of web application.
Are there any options to execute client side code under some checks? For example: Setting a particular IP address as secured in order to by pass security checks.
Java Web Start is probably the way to go for this deployment.
The issue people do not want to download the jar, they want pre-installed jar to be executed
The point is that 'the user' does not download the Jar, instead that is done invisibly by the JWS client that runs the launch file the user clicked. Try my JWS version of GIFanim for an example of the experience.
Note that even though that app. is sand-boxed, there are still prompts before it reaches the screen. Since version 1.7.0_21 those prompts apply to both applets & JWS apps.
Ultimately, there is no way to run a Swing based app. before the Jar is downloaded. E.G.:-
User downloads executable Jar & runs it. They need to download the Jar in a situation where it is clear the Jar is being downloaded.
Applet. The JVM will be invoked when the applet element (or equivalent) appears in a web page. The JVM will download & cache the Jar - relatively invisible to the user, excepting the 'loading..' progress bar in the applet.
Java Web Start. The JWS client will be invoked when the user clicks a link to a JNLP file. That JNLP will be cached locally, then the resources (Jars etc.) will be cached locally, then the app. will be run. Again, relatively invisible to the user, barring the download time and any related progress indicator (which JWS does by default).
..when individual product owners click on their products then product specific jars need to be executed to open Swing UI.
You would have a JNLP for each 'more specific' app. as well, then you might use the BasicService of the JNLP API to invoke the relevant app. by opening the JNLP of that app. Here is a demo. of the BasicService.
use web start
see this link
http://www.oracle.com/technetwork/java/javase/overview-137531.html
web start allows the client to run java application where the jar reside on the web
Related
I have a Java web app that I run on an Azure App Service instance. To deploy it, I use a Bitbucket repo with a .war file inside it. When I commit a new .war file to this repo, it is supposed to be deployed automagically by the service. However, more often than not, I have to either restart, re-deploy, or even upload the .war file via FTP for the deployment to be completed successfully.
I have a single Jetty instance residing in this service, hence my .war file is named ROOT.war. AFAIK, when uploaded to the service (whether via Bitbucket or FTP), this .war file should be unarchived into the same directory, which is /site/wwwroot/webapps. In my case, this doesn't happen. The web app works with the ROOT.war file sitting alone inside /site/wwwroot/webapps. And every once in a while, I get a ROOT folder under /site/wwwroot/webapps, with two default files index.jsp and background.png. I don't have the slightest idea what causes the ROOT folder to appear with these default files. The only clue I have is that it happened a couple of times after I changed an environment variable.
Also after the ROOT folder appears with the empty server files, the only way I can re-deploy the app is to manually delete this ROOT folder via FTP or the console provided in the portal, and only then my re-deploy request succeeds with my web app.
So, if it isn't clear enough, my question is what is going on here? I can't make anything out of the behaviors I'm facing. I feel like I'm using this Azure service blindly, and can't get to fix anything when something goes wrong. Are there any resources that may explain what happens in the background when a web app is deployed?
So, Azure API Apps are a PAAS, not IAAS service. You can access the PaaS platform by coming to yoursite.scm.azurewebsites.net, where you can browse the file system in CMD or Powershell, and you can see the running processes. This may feel like you are on a single VM, but you are not. The data you see here is replicated down into your API App instances. You can control how many instances you have through scaling your API App.
I have commonly seen your issue with deploying, then ROOT being empty(working internally to see this fixed...).
The best method that works every time for me, is to stop your API App, manually UNZIP your ROOT.war. Move the files into /ROOT/, then to start your API App.
You can simply place ROOT.war, and let the system unpack it when you turn it back on, but this can sometimes lead to that empty ROOT directory, then requiring another restart.
All of this has me moving to Spring-Boot instead. No unpacking required. Simply configure your web.config and drop the jar file.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-java-custom-upload#springboot
I had the same problem. The solution is to call the endpoint after de deploy.
Stop the Azure App Service.
Deploy the ROOT.war artifact in the /webapps folder.
Start the Azure App Service.
Call the URL of the App Service once.
The four-step is very important and start the process that you mentioned before (the automagically deploy).
I lost a lot of time figuring out what was the problem.
Oracle recommends using the JnlpDownloadServlet to launch JNLP from Java web applications - https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/downloadservletguide.html
However, I need to launch a JNLP application with a dynamically generated JNLP file from a dotnet application.
What would I need to do to enable this?
set content type as application/x-java-jnlp-file
output the JNLP file as a download.
Is there anything else?
The JNLP file is just an XML file that happens to be an executable file as long as you have Java Web Start installed on your machine. This is usually installed on a machine.
From a .NET Web Application point of view, you'd need to ensure the following:
Correct content-type (application/x-java-jnlp). You might need to add configuration to your .NET server to enable this mime type.
The file needs to be accessible via a URL (kind of obvious, but worth mentioning for completeness)
The file needs to be downloadable. Conceptually it is the same as returning any other file.
For seamlessness, the browser needs to be setup to automatically execute jnlp files. Sometimes company/default browser settings do not do this and you'd end up needing an extra click. Not a big deal, but just something to be aware of
In terms of "configuring"/implementing the actual serving of the JNLP file from a .NET Application:
Your end goal is that whatever JNLP file you return is executable with Java Web Start. This gives you a nice repeatable test while you're working on this.
You need to ensure that your .NET Application is able to serve the jar files needed by the JNLP application. Typically the codebase attribute and the resources element needs to reference your .NET application. The JNLP File Structure Page should help with this.
If you look at the JNLP servlet source code you will see that all it does is use the .jnlp file as a template and substitute place holders for specific values. There is nothing special about it that couldn't be duplicated in a .Net MVC or API controller.
I export my maven java project in Eclipse to War file.
On the server, I open the manager of tomact and add the war application, but when I run the application it seems the application isn't running (or some problem with the resources).
From the other hand, when I start the tomcat by the startup.bat in the tomcat folder and add the War to the webapps folder, it is working. But if I logoff the server , I cannot connect the application remotly. The server is shut down. Why?
What can be the problems?
Thanks!
Me
Why is your application not running? Well - if there's a specific reason for it (and the manager application works) you will see it in the logfile - e.g. tomcat's log/catalina.out. Check it or give us a snippet of the error messages in there if you don't understand them.
I like to recommend not to use the manager application, rather deploy through the OS or any other maintenance tool (e.g. scripted). This typically results in a better maintainable system. As it already works well for you when you just add your WAR file to the webapps directory, everything seems well. Introducing a manager application in production just provides another means to attack your site - and I frequently see those applications poorly maintained (and the passwords poorly chosen & protected)
When you start tomcat with startup.bat, it will run the server process in a console window. This console process will be shut down when you log out. In order to have tomcat running even when you're not logged in (and in order for it to start automatically), you'll have to install it as a service. There's plenty of information on the internet on how to do this - should be extremely easy to find.
if the top of your JSP reads
<%# page contentType="application/x-java-jnlp-file"%>
<?xml version="1.0" encoding="UTF-8"?>
How do you add html to this page?
Equally, How would you get the web browser to create a popup for instructions?
How do you add html to this page?
If you do, it won't be a JNLP file. It will be a mess that is pretending (poorly) to be a JNLP. Most JWS clients would reject it, pointing out that it is not JNLP, the rest would fail with other (less obvious) errors.
Equally, How would you get the web browser to create a popup for instructions?
Aaaargh, the dreaded pop-ups. My browser would kill them automatically.
Put instructions on the page that links to the JSP that launches the app.
Why not write a regular servlet for it? JNLP files are not html and i dont even know how that would work with JSP.
And if you send a JNLP most web browsers will know what to do with it, you can also distribute this file through email(or other means) and start it directly on the users computer.
I used to have several WebStart apps a few years ago and i wrote a servlet that would just serve the JNLP file from the local file system. I later changed it to generate the JNLP file on the fly and include default libraries i used in all my projects. I also used that to serve the jars from the file system so they didnt need to be bundled with the servlet WAR.
I put some of my code here http://ideone.com/36sjB as a start. Most of it was used in an experimental in house app, so this should not be used in production code ;).
Sending the JNLP is just like sending the jar with a different content type. I also have code about generating the JNLP from scratch through the servlet if you are interested.
My company has developed a web application (J2EE environment/Tomcat server) and wants to sell it as a product. Customers can avail this product as basic edition or premium edition. In the premium edition the customers have some extra functionalities (may be some extra links). This distinction is made based on the serial key.
I was just a listener when the above thing was discussed.
Is doing the above problem possible? How do we convert a war file into an exe file and embed logic to distinguish premium or basic version.
How do we convert a war file into an exe file and embed logic to distinguish premium or basic version.
These are 2 distinct requirements which have nothing to do with each other.
If you have a web application you can either enter the serial key using a web page (like Jira does for instance), or you could perhaps let the key (or the filename of the keyfile) be written in Context.xml, and let a servlet read that context parameter. Based on the key the application could then allow or not allow some functionality.
As for converting to an executable, there are multiple interpretations to the word executable. I for one think "war" file is executable enough - dump it in a tomcat and it runs.
If you want it standalone you could provide a tomcat distribution with your app predeployed (again, like Jira does), or use a Jetty embedded container. Although that may not be appropriate for heavy workloads.
You could even try to convert jetty + your web app to a native exe using gjc (Gnu Java Compiler) though I doubt it will work as well as the normally deployed version.
I'd advise you to either inject the key via context parameters, or create an admin page n which you can enter the key.
A WAR is a web application archive. It's supposed to be executed on a webserver with a servlet container. An executabele JAR requires a class with a main() method, but a web application normally doesn't have any since that's the responsibility of the servlet container, not the web application. Normally, a WAR is to be distributed as-is, it's the serveradmin's responsibility to deploy it to a servlet container. You can if necessary include some documentation which describes how to do it for various containers.
If you really intend to sell a web application as a desktop application for some unobvious reason, then your best bet is really to include an embeddable servlet container like Jetty and ship a class with a main() method along it which creates an instance of the embedded servlet container, deploys the WAR file to it and runs the servlet container. This can in turn be wrapped in an executabele JAR.
Alternatively, you can also host it somewhere on the internet and provide a specific login.