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.
Related
i have written a small java application which is called by an java application running as a windows service.
My java application calls the print method in order to print the word document:
java.awt.Desktop.getDesktop().print(new File(targetfile));
It works if i call the java application but it does not work if it is executed by the windows service.
What happens is that i have multiple ms word processes running in the background each time the window service tries to execute my java application.
Do you know how i can print from a windows service ?
Thanks,
Asad
If I had to guess... you need to run the Windows Service as a user with appropriate permissions to print.
By default a service will run as System or LocalUser, which will not be able to print. That's why it works when you call it but not the service. Try and set the Log On account for the service to your personal account and see if it works.
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
I configured a job for doing GUIAutomation(which got developed using java code including running commands and keyboard events) in the targeted machine.
Extra Info:-
I am running a command to launch the installer(installer GUI should come).....but its not happening
When I got any error I am capturing a image using JAVA DefaultToolkit API, but very time its coming as Black, nothing there to watch.
GUIAutomation tool was developed by myself.
Please help me to overcome this problem, since I have to automate it through jenkins.
Usually, problems running GUI programs in Jenkins occur because of the Jenkins service not having privileges to access the display of the slave (or master, you don't mention which) that is running the job. A typical solution is to start the slave via JNLP, which requires logging on to the slave, navigating to the slave's page on the jenkins master (via browser on the slave) and launching the slave process via the button on that page. You can also launch using the javaws command which will be shown on the same page.
On Windows slaves running as a service, you may have success by configuring the service to run as a user with login and desktop privileges for the slave - the default is the Local System user which has no such rights.
I have done the same job as you.
You have to create the jnlp connection. I create one batch file in slave machine such as: jar -jar slave.jar -jnlpurl (your url)/slave-agent.jnlp
If it's remote slave, it's better to use VNC instead of remote desktop when you operate that machine. Because when you close the session, remote desktop will hold the session, so the screenshot would be black.
I have been working on a Web Application for Intranet use only. I work with Apache 7 and Windows Server 2003.
In one of my page, I need to open an external application that we can locate in C:/Program Files/etc... with some parameters already initialized. Of course, the user has to use the web application on the server to make it work (that will be the case).
To open the application, I use the ProcessBuilder object.
The problem:
When I work locally with Eclipse and run the server by hand, it works perfectly. Any application can open itself from a web page.
But when I use the tomcat windows service (and that's what we want to use on the server), it just never launches. Or to be more specific, it launches and stops the application directly. No java errors thrown and process.waitFor() with an exit value of 0. The fact is that we can run processes via the web application (I tried to run simple batch files), but when there is an UI involved, it will never appear.
Again, on the server this time, if I launch tomcat7.exe (that we can find in the %CATALINA_HOME%/bin directory) with a double click or cmd, the UI in the web application will appear. If I launch it with services.msc or tomcat7w.exe or tomcat7 start via cmd, it will not.
I thought of several things:
use another user to start the service
change the way the service is launched (StartMode: jvm, java. I did not succeed with exe)
I read Tomcat 7 Windows Service How-To many times but didn't find out anything to solve my issue.
Have you any idea of what is happening, and how to solve this issue ?
What is the big difference between running tomcat as a service and from the command line?
Option 1
If you open your service's properties window, go to the Log On tab then check the "Allow service to interact with desktop" check box you will get the behavior you want. Also depending on what app you what to run you may need to change the log on account.
see Launching GUI App from Windows Service - Window Does Not Appear
Option 2
Did you try start a cmd and there use
start /c "c:\path to\exe"
in cmd.exe type
help start
Option 3
You will need a daemon service that is not run as a service. windows puts certain restrictions on service apps.
This sleeping app can be started by tomcat or other your self. it can listen on a port or poll a folder for a new file, and when it gets a job to do it starts the app you want. Via port or text file you can send the parameters.
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).