I have a Java Application(works as server for a client application) with a GUI. This application has to run always even after restarts of the server.
I have created a windows service using Apache daemon for this purpose.
When the server starts I can see my services running as system service. But when I open the GUI of the application another instance starts.
I need the GUI to be attached to the same instance which started after restart, is this possible.
A Windows Service (as well as daemons on Unix-systems) can't run with a GUI because it starts without a Window Management System like Windows Desktop or KDE, Gnome, etc. I'm actually surprised that your application starts as a service because attempts to start GUI-elements should lead to an error.
You have to separate the GUI from the server components. The GUI then needs to communicate with the server by some protocol. Because you already have finished your application I suggest RMI as protocol of choice, that should be the easiest to implement because you essentially just have to add some interfaces to your classes to get RMI on its way instead of adding a complete layer of complexity by your own (an additional server to receive commands from the client, etc.).
RMI can be set up to only listen for connections from localhost, so in terms of security you should be good as well.
Related
I have an Linux server, and i have 2 Java applications.
1- ServerApp.jar. This application is on my server.
2- PcApp.jar. This application is on my computer.
May i make ServerApp.jar application run, by click on button in PcApp.jar application?
There are ways to download and execute the remote jars at client place.
But for your problem of invoking some operation on remote machine itself, you'll have to fall back to RMI or services implementation on server side and trigger them inside PcApp.jar
In the 12 Factor article on Port Binding
http://12factor.net/port-binding there is a requirement that every app
be self-contained and not have a runtime injected e.g. Tomcat. For
what reason is this advised... what are advantages of self-contained apps for microservices?
To understand rules around port binding and self-contained apps, it's helpful to view things from the perspective of the platforms designed to run 12-factor apps, like Heroku or Deis.
These platforms are scaling applications at the process level. When processes are scaled up, the platform tries to place these additional workers behind the routing mesh so they can start serving traffic. If the app is not self-contained and, for example, is tightly coupled to a front-end Apache server using mod_jk -- it is not possible to scale by running more isolated worker processes.
Port binding exists to solve the problem of "port brokering" at the platform level. If every application worker listened on port 80 there would be conflicts. To solve this, port binding is a convention whereby the application listens on a port the platform has allocated -- and which is passed in as a $PORT environment variable. This ensures a) the application worker listens on the right port and b) the platform knows where to route traffic destined for that worker.
I think is because it gives you a great deal of flexibility when the time to scale up your app comes. If you use tomcat you'll have to copy your .war and drop it inside another tomcat and then load balance your requests to either of them.
Instead If your app has a self contained http server, you colud just run another instance in another port and forget about all that tomcat stuff. You would still have to load balance your requests to either of your app instances, but seems more straight forward.
I have a desktop application that is written in Java and that I have source code for.
I want to launch a process in this application based upon when I click a button in my web application.
I'm thinking that the browser can fire off a HTTP call to the desktop application on the loopback address. The application will only listen on the loopback address thereby preventing other machines from talking to the application.
If I take this route, I have to host some kind of http listener in my java desktop application. What is the best way to do this?
I have considered embedded tomcat and jetty, but I'm wondering if those aren't overkill or less secure due to a larger feature set, and I could run a http socket listener with something simpler.
I've got this new project at work. We are using Eclipse for the project. There are two run configurations, server and client. I have to launch the server and the client independently, and connect to the server using the client. Now, it so happens that this has to be done on both Windows and Linux. (four possible combinations: WS-LC, WC-LS, WS-WC, LS-LC, where W-windows, L-linux, C-client and S-server)
I have Linux on my machine (in which Eclipse is running) and run Windows on a VM. Is there a way I can make Eclipse launch the application in the VM?
I understand I have to build the application locally to a shared folder and send a launch command to windows (using openssh?, not sure). What are the best practices used in this scenario.
EDIT: I need to use this during development, to test my changes to the code. The same application provides both client & server. (yes, horrible, i know :X )
You can publish the server functions as JMX Beans using the MBean interface standard. Then use JMX Console to remotely connect to the server JVM and launch the application.
Eclipse has integration points for remote servers, look to "tomcat configuration" for an example of how it integrates with one remote server.
Whether your application can use an existing server integration solution or not depends heavily on details which aren't present. If you want to actually launch a stand-alone Java process from your remote machine, you generally need a program to capture the request and launch the process.
I am planing to develop a profiler by using the JVMTI API provided by Oracle. For a visualization I would like to implement a GUI (Qt framework) on top of the agent code. My first jvmti agent is aready compiling and running and I started to integrate the agent into my Qt project.
Now I am facing the problem how to couple agent with GUI. Should the GUI be launched inside the agent? For instance in the Agent_OnLoad function?
A long-term would be to start the profiling out of the GUI, though I cannot imagine how to realize that.
Well.. you have a number of choices the most obvious would be socket based comms. You'll have to assume that the majority of profiling use cases will involve a remote headless JVM on a server. In my profiler you can operate headless with a small start/stop/control utility on the same machine as the agent, data is collected on the server and transfered to the client for visualisation. You can also start the remote (or local) jvm with the agent and connect to the listening agent over a socket from the full GUI.. collecting over that socket to the client.
There is also the new "JVM Attach API" which allows you to "insert" an agent into an already running JVM, therefore if the target machine is UNI* then you could use ssh/scp from your GUI and script an sCP transfer of the agent to the server and SSH to initiate the attach.
So... sockets (IP and/or domain) and reuse that code from the GUI for a headless control/collection client