I want my Java application to be an interactive windows service (a windows service that has GUI when the user is logged in).
I searched for this and I see that the way to do it is to have 2 programs, 1st is a service, 2nd is a GUI program and make them communicate - the service will get commands from the GUI program.
Just before I started to split my program, I noticed that in "Java Service Wrapper" there is a flag:
wrapper.ntservice.interactive=TRUE
Is this flag an automatic way to do the same as the following manual config?
administrative tools -> services -> right click -> properties -> under
Log On tab check allow to interact with desktop
Is this way problematic? Should I go for the long way and split my program into two programs (GUI and service)?
thanks
Prior to Windows Vista, all services and application were run in the same session. This provided the convenience of allowing Windows services to have front-facing UIs and interacting with users directly, but it also posed a security risk. For example, a Windows service that runs with elevated user privileges (e.g., admin rights) could potentially be compromised through exploits of the UI.
Beginning with Windows Vista, Windows services are isolated in Session 0 while all user logins and applications are run in other sessions. Technically, Windows services can still interact with the desktop via Session 0, but ordinary users have no convenient way of accessing Session 0. So while your Windows service can pop up a confirmation dialog box, the user will never see it because it displays in the Session 0 desktop. Further, the user will be unable to confirm the dialog, meaning that the Windows service remains "stuck."
In short, having your Windows service interact with the desktop is no longer feasible. You'll have to create the Windows service and then a front-end application and provide some means for them to communicate, e.g., pipes, sockets, shared memory, etc. The recommended way to do this in .NET is to use the Windows Communication Foundation (WCF). I'm not sure how easy this is to do w/ Java, and in the spirit of full disclosure, I use sockets myself.
HTH
Related
I've created a java program which is installed as a Windows service on a win10 machine using winsw. This program needs access to the current user desktop as it periodically creates screenshots (using java.awt.Robot) and processes them.
Because windows services run in their own session0 that isn't possible (I get black images). So how can I create my screenshots without creating another program which is run by the user session itself?
You should set <interactive> True in your configurations file in order to allow service to interact with Session 0. But in UAC OS(Windows vista or Above) services are no longer allow to interact with the Desktop.
ex :- <interactive />
For further information read this.
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 have a gateway application that comes up with a login dialog and then a GUI window. I will be running this app on a co-located server without a display. I need to interact with the dialog only when logging in and perhaps to check out the main GUI occasionally. The server is Debian 5.0.
The only ideas I have so far are:
Tunnel an X session to my desktop for logging in but I'm not sure what will happen if the X session disconnected (ie, I reboot my desktop, etc..)
Try to instantiate/launch the app from a wrapper Java application that can hopefully fill out the login dialog or login directly however I would most likely lose the ability to see the main GUI this way and other side effects might occur.
It's too bad this particular app was written in Swing and doesn't provide a command-line only mode or daemon mode.
You can run a VNC server on the machine where the application runs. Then you can connect to the virtual X-server at any time to interact with the user interface.
I don't have a Debian system nearby, but on Ubuntu there is a package vnc4server that provides the features you need.
My Java.app broadcasts a packet on the network as soon as it starts up. Everytime I start this app, the Mac asks me do I want to allow network connections blah..blah.. Can I use info.plist or something to allow network access to this app and not bother the user who has trustingly downloaded and installed my app.
Thanks
You can choose to allow incoming connections for specific services in System Preferences > Security > Firewall.
Addendum: You application will appear only if the user has chosen to "Set access for specific services and applications." It will be added the first time the application attempts to open the port.
Addendum: The application appears with the name java in the Firewall pane. Once the user chooses to accept or deny, the dialog ceases to appear. This simple example is convenient for testing.
If you codesign your app (using the same key across updates) it should work properly with the app-specific firewall on. It seems to be a bug on Apple's side that unsigned java apps are prompted for allowing network connections (even if they don't try to listen to the network) every time they are run.