I am currently learning JSP and Java Servlets. I was wondering if there is any way to call a java GUI from a JSP, not necessarily to load into the page, but to load onto the screen for database input. I am struggling trying to find some reference on how to do this on the net, but no luck so far.
You could use Java Webstart to start up the application on the client side. Or, ask the user to install a local client differently (like a daemon service).
The "GUI application" must have some kind of RPC (=remote procedure call) service running in background.
Once the client has your gui application installed, the JSP can invoke urls on http://localhost:port (ajax would help sending messages to the GUI application). The GUI application must have some rpc system (rest, webservice) that receives the requests from your web application (your jsp app) and start the GUI requested by the URL.
The problem here is to make sure the client has the port of choice available.
Another possibility is to register some URL to your application in the client side, so that when the user clicks a url like myapp://form/123 the OS automatically invokes your application to handle that URL. This kind of thing must be done differently per operating system. It's the way it works when you click on a magnet link or a skype://link. The procedure to register urls in the operating system is different per OS, you need to do some research (I never did that, but I am sure it is possible). You can also register a file extension to your app, and make sure that the specified extension is registered to your app. When the browser downloads the file and opens it, your app is invoked with the file downloaded as parameter (which will contain the instruction for your GUI). But most browser will not start automatically the app associated to the file after the download: again, you need to do some tricks on the client's operating system to make the "download and open" the default behavior for the browser.
Related
Our app heavily makes use of applets to check-in (upload) and check out (download) files from users machine. Can someone please confirm what are the alternatives for applet (as it is going to be deprecated by Oracle in 2018)?
We had the same problem. We were using applets in our web application for printing, scanning etc. on local machines. We solved the problem with a simple Java Web Start client application that has a simple web server embedded (Jetty). Now when user starts the web application the client application is downloaded, if necessary, and started on the local machine. It sits there in a tray and listens for requests from the server side application. Handlers are implemented for different types of requests. When client side receives a request, it hands it over to a responsible handler, which executes its task and creates a response, that is sent back to the server side.
For now, this solution works perfect and we could reuse most of the applet code.
I have a simple cloud IDE,I want to make it able to build and run applications remotely, the target application's source files will be in a remote server in isolated virtual machine (e.g Windows 8.1,or Ubuntu 14.04). It's not difficult to build that application but how to run it and view its output to users ?
What if it's a desktop application (suppose it's written in C# or Java or Python)?
Note: users access there applications only using browsers (e.g Firefox,Chrome,...)
Edit: desktop application may contains GUI stuff not only console ;)
You need a web application.Now this web application when loads send request to backend code that backend code will do SSH to remote machine and read the file from specific location.Now that read stream will be send back in response and displayed on web based UI. In these type of application few thinks matters.
1) Like if you whole file at once then it will take time to display that content to user.Better idea will be read around 100 lines at once and when user scroll down then again send request to web server to read next 100 lines in this way you can decrease response time and better user experience.
Each of the languages you mentioned offers a Web Services framework of some kind. Pick one, and implement something that a) starts your app, b) shows the output. Depending on the processing time (how long it takes to complete) you might even get away with just one.
You can go for a self-contained, standalone service:
C#: Is it possible to create a standalone, C# web service deployed as an EXE or Windows service?
Python:
Best way to create a simple python web service
Java:
https://technology.amis.nl/2009/06/05/publish-a-webservice-from-a-poja-plain-old-java-application-that-is-out-of-the-container-using-endpoint-class/
Alternatively, you might use a container (server) for your app, like Apache with mod_mono or IIS for C#, Tomcat, Jetty, Jboss for Java, Apache with mod_wsgi for Python (just examples).
The web service would probably sit on the remote machine, so it could use system calls ('command line') to run your core app, and then it would send the results over http. Since you mention GUI, there could be more layers to the solution:
The GUI - static HTML, desktop app, sending requests to the 2nd layer, say displaying dropdowns for parameter1 and -2
The Web Service - takes the params from the request, say http://remote.machine.land/start/app?parameter1=X¶meter2=Y, runs a local command like /home/users/myapp.sh -parameter1=X -parameter2=Y
The application itself - not necessarily aware of any internet out there.
This way you stay free to change/enhance any part at a time, call the 2. layer programmatically, introduce load-balancing, etc.
3.
I have a web application running with support for some specific pieces of hardware. This is achieved in the following steps:
User runs a small installer that places java files (and a couple
others) on the client machine. The main piece is a jar called "hardwareManager"
User visits web app. The web app runs a java applet which, due to
a .java.policy file placed during the install, has permission to
interact with the client machine outside the browser sandbox.
The applet checks to make sure the hardwareManager is running,
and if not runs a command to start it.
User interacts with the web app which sends commands to the applet via
javascript. The applet then writes commands to a text file
on the client machine. The text file is constantly monitored by the
hardwareManager which runs any commands it reads in.
This works, but seems clunky. I have a couple ideas on how to improve it, but I don't know which, if any, are even worth trying.
Would it be better to set up the hardwareManager as a socketServer and have the applet connect directly to it, rather than going through text files? Is that even possible?
Is there a way to eliminate the applet altogether and have the javascript talk directly to the hardwareManager? Maybe by writing the hardwareManager to be a local http server? What port should it run on? Do javascript xss limitations fit in here somewhere?
It would be less clunky to start the Java application using Java Web Start. This would remove the need to daemonize or install the Java hardware manager.
Another alternative is to use a built-in browser inside Java. I supose this is not an option, since you depend heavily on Javascript (I suppose to provide a rich client experience).
If you already have to install something on the client machine, why did you make the choice to go with a web application?
Talking from experience: We had a Java EE application which needed to print to PoS printers at the client site. We installed a small "synchronizer" application that connects through SSH and synchronizes all clients files. Afterwards, it loads the JAR and executes the program. This program connects through RMI with the server and subscribes to a JMS queue to receive the print assignments.
Applied to your case: Why not let your Java application connect to the server directly? You can use HTTP, SOAP or even JMS over RMI. You can then launch the hardware command from the server (instead of from the limited JavaScript webbrowser environment). This way, you get tons of features: authentication, buffering of commands, and you can even share hardware between multiple clients.
Schematic:
<----AJAX------> Web browser
ApplicationServer
<---HTTP/SOAP--> Java hardware manager application
You can launch the Java application using Java Web Start, which allows you to update the application automatically (instead of needing to pass every client a new installer).
I'm remote controlling a Java application on a PC through an Android phone, and I needed my application to open a browser at the phones command, chrome in this case. I created a "Process" for chrome, opening a certain address. However, I need to be able to give tools on the Android phone for controlling the web page, such as scrolling. Can I programmatically send a command for chrome to scroll from my PC application containing the Process?
Sorry, it may have been unclear, but the only connection the android phone has to the program is through a socket. It is only used as a remote control for another Java application on a PC, which has its own screen.
I do not think that clean solution exists.
But I can suggest the following directions:
(1) try to investigate the native chrome API. If it has such ability call it with JNI.
(2) Try to use class java.awt.Robot. It allows to simulate user's activity, e.g. mouse clicks. Unfortunately it does not allow you to find any window outside your application, so it is a problem to decide where to perform the click.
(3) You can create proxy server and make browser you open to go to the target URL through the proxy. The proxy server will insert into the page your javascript that will communicate with server. The application that opens browser will send commands to server. The javascript that you inserted will receive these commands using AJAX and perform them. JavaScript can scroll browser window, so theoretically you can implement this.
If you can target the tab you want to control and edit the address bar you could send the command 'javascript:scrollTo(x, y)'. I just tested it on this page and it seems to work fine, replacing what I typed with the original address of the page.
Can I programmatically send a command for chrome to scroll from my PC
application containing the Process?
Not directly. What you could do is make some sort of web service that sits between the Android client and page that the Android client can send commands to and the page can periodically poll via AJAX calls to see what the client wants. That would be a clean DIY way that would work on other browsers besides Chrome.
You can use vnc viewer applications for that.
http://code.google.com/p/android-vnc-viewer/
I have a Java Applet application. The use case is as follows:
The users invoke a URL which is mapped to a Servlet. The servlet as a response returns a JSP page from which the users can navigate in the UI. The entire UI is made of Swing [basically a JApplet]. The events in the UI are handled in the traditional manner [ActionListeners, SelectionListeners...]. Now I have the following requirement:
There is a file in the server directory that I am supposed to allow the users to download through my application. I need to give the users a link in my UI, the clicking of which will trigger the download.
Can this be done considering the security features of JApplets? Also consider the event handling mechanism of Swing components.
The options for a sand-boxed applet.
There are 2(.2) ways to go (that I can immediately think of).
Use the AppletContext.showDocument(URL,String) method to trigger the download using the browser.
For 'Next Generation' plug-in 2 based applets (1.6.0_10+ in Sun/Oracle's JVM) it is possible to hook into the functionality of the JNLP API of Java Web Start.
The JNLP API provides the ability to access the local file-system in a sand-boxed application or applet. Here is my little demo. of the JNLP API file services.
The JNLP API also provides the BasicService.showDocument(URL) method. This version is slightly superior to the AppletContext equivalent for the fact that it returns a boolean to indicate success/failure. The applet based version might fail, and if it does, it does so silently. See also the demo. of the BasicService.
A trusted applet can use this process.
Pop a JFileChooser to allow the user to decide where to save the File.
If the chooser returns a valid File (indicating the action was not cancelled) proceed with saving.
Get an InputStream from the URL.
Establish an OutputStream to the File.
Read bytes from the InputStream, write them to the OutputStream.
Rinse & repeat till read produces -1.