I have a client-server application in Java and it is basically a remote control software. I need client to run in Windows startup, I searched and found some ways to do that.
1- Adding shortcut or file to Startup folder
I can't do that since there is a possibility to user can delete it from folder.
2- Writing it to registry
That's exactly what I want but, I don't want to use 3rd part applications or sources. I couldn't find a way to do that on my own.
3- Wrapping it as a windows service
That's also okey for me, however, there will be multiple client's so i need to do that process each time. Thus I can't use it.
If you can help me, give me an idea or indicate my mistakes on topic, I will appreciate.
You could use a Task Scheduler. This would allow you to run it on boot as well as other types of triggers.
https://www.howtogeek.com/138159/how-to-enable-programs-and-custom-scripts-to-run-at-boot/
Related
I would like to implement a java application (server application) that can download a new version (.jar file) from a given url, and then update itself at runtime.
What is the best way to do this and is it possible?
I guess that the application can download a new .jar file and start it. But how should I do the handover, e.g. know when the new application is started and then exit. Or is there a better way to do this?
The basic structure of a solution is as follows:
There is a main loop responsible for repeatedly loading the latest version of the app (if required) and launching it.
The application does its thing, but periodically checks the download URL. If it detects a new version it exits back to the launcher.
There are a number of ways you could implement this. For example:
The launcher could be a wrapper script or binary application that starts a new JVM to run the application from a JAR file that gets replaced.
The launcher could be a Java application that creates a classloader for the new JAR, loads an entrypoint class and calls some method on it. If you do it this way, you have to watch for classloader storage leaks, but that's not difficult. (You just need to make sure that no objects with classes loaded from the JAR are reachable after you relaunch.)
The advantages of the external wrapper approach are:
you only need one JAR,
you can replace the entire Java app,
any secondary threads created by the app, etc will go away without special shutdown logic, and
you can also deal with recovery from application crashes, etc.
The second approach requires two JARs, but has the following advantages:
the solution is pure Java and portable,
the changeover will be quicker, and
you can more easily retain state across the restart (modulo leakage issues).
The "best" way depends on your specific requirements.
It should also be noted that:
There are security risks with auto-updating. In general, if the server that provides the updates is compromised, or if the mechanisms for providing the updates are susceptible to attack, then auto-updating can lead to a compromise of the client(s).
Pushing a update to a client that cause damage to the client could have legal risks, and risks to your business' reputation.
If you can find a way to avoid reinventing the wheel, that would be good. See the other answers for suggestions.
I am currently developing a JAVA Linux Daemon and also had the need to implement an auto-update mechanism. I wanted to limit my application to one jar file, and came up with a simple solution:
Pack the updater application in the update itself.
Application: When the application detects a newer version it does the following:
Download update (Zipfile)
Extract Application and ApplicationUpdater (all in the zipfile)
Run updater
ApplicationUpdater: When the updater runs it does the following:
Stop the Application (in my case a daemon via init.d)
Copy the downloaded jar file to overwrite current Application
Start the Application
Cleanup.
Hope it helps someone.
I've recently created update4j which is fully compatible with Java 9's module system.
It will seamlessly start the new version without a restart.
This is a known problem and I recommend against reinventing a wheel - don't write your own hack, just use what other people have already done.
Two situations you need to consider:
App needs to be self-updatable and keep running even during update (server app, embedded apps). Go with OSGi: Bundles or Equinox p2.
App is a desktop app and has an installer. There are many installers with update option. Check installers list.
I've written a Java application that can load plugins at runtime and start using them immediately, inspired by a similar mechanism in jEdit. jEdit is open source so you have the option of looking to see how it works.
The solution uses a custom ClassLoader to load files from the jar. Once they're loaded you can invoke some method from the new jar that will act as its main method. Then the tricky part is making sure you get rid of all references to the old code so that it can be garbage collected. I'm not quite an expert on that part, I've made it work but it wasn't easy.
First way: use tomcat and it's deploy facilities.
Second way: to split application on two parts (functional and update) and let update part replace function part.
Third way: In your server appliction just download new version, then old version releases bound port, then old version runs new version (starts process), then old version sends a request on application port to the new version to delete old version, old version terminates and new version deletes old version. Like this:
This isn't necessarily the best way, but it might work for you.
You can write a bootstrap application (ala the World of Warcraft launcher, if you've played WoW). That bootstrap is responsible for checking for updates.
If an update is available, it will offer it to the user, handle the download, installation, etc.
If the application is up to date, it will allow the user to launch the application
Optionally, you can allow the user to launch the application, even if it isn't up to date
This way you don't have to worry about forcing an exit of your application.
If your application is web based, and if it is important that they have an up to date client, then you can also do version checks while the application runs. You can do them at intervals, while performing normal communication with the server (some or all calls), or both.
For a product I recently worked on, we did version checks upon launch (without a boot strapper app, but before the main window appeared), and during calls to the server. When the client was out of date, we relied on the user to quit manually, but forbid any action against the server.
Please note that I don't know if Java can invoke UI code before you bring up your main window. We were using C#/WPF.
If you build your application using Equinox plugins, you can use the P2 Provisioning System to get a ready-made solution to this problem. This will require the server to restart itself after an update.
I see a security problem when downloading a new jar (etc.), e.g., a man in the middle attack. You always have to sign your downloadable update.
On JAX2015, Adam Bien told about using JGit for updating the binaries.
Sadly I could not find any tutorials.
Source in German.
Adam Bien created the updater see here
I forked it here with some javaFX frontend. I am also working on an automatic signing.
I'm currently looking into what better ways there are for deploying/setting up webapps locally after code changes and database changes.
So far I've seen the following tools/ways come by, and attempted each of them:
ANT build target that compiles, makes a jar, a war file and deploys that to the tomcat folder
Gradle build in combination with the tomcat plugin, which already does a bit of a better job than option #1
Good ol' fashioned command line
Setup run configuration within Intellij to do the deployment for you
Write shell script and call this via command line (haven't tried this)
To be honest I'm not finding each of these the ideal solution. I find option #4 the easiest as it allows me to, via a short-cut, easily deploy my changes and continue. This has however not given me an option for database changes yet, probably just me that missed it.
My question is mainly what tools/ways are you guys using in order to achieve an easy and maintainable development environment? What considerations come with those?
Well, let me tell you what I do for local web app setup.
In your favorite IDE(eclipse in my case) i'll configure the application server plugin(tomcat or webpshere) from Eclipse marketplace.
This setup will help to auto publish code changes to the server whenever I make a change in the application. I use Maven build tool for the application packaging. However I'm not sure about the database side.
For the people that were wondering how I ended up doing and found the best to work for me.
I currently have configured my IntelliJ IDE in such a way that the tomcat instance is linked and can be properly controlled and deployed, including debug, from within IntelliJ itself. This allows me to, via an easy shortcut, instantly populate any resources changes (css, javascript, front end) or redeploy or even restart the server. Especially with a small application this works very well.
It is yet to be determined whether this would still work with a multi-module setup and a larger project size.
Should you want more information on how this configuration can be achieved, feel free to send me a direct message.
I have a jar file which contains two Java classes. Using the javamail API I have developed these classes to read and edit my mail, then send to another mail id.
I am able to execute this through my standalone system via Eclipse. Now I want to host this jar file somewhere remotely so that it would fetch the data in real time and execute the job regularly. I have contacted couple of hosting sites and they are saying that they require a war file instead.
Does anyone have any suggestions to this problem?
To give you another point of view and to be constructive, I would go with embedding your jar into a war application and you get some things for free, the most important I think is that you gain a managed application lifecycle so with a standard web application context listener you can start and stop your program in a managed way. Besides you have more hosting options and it is less work.
Good luck with that.
As I don't know of any services specifically for plain execution of executables, your best bet is probably getting a cheap VPS. With some searching you can probably find one that would work for around $5 USD/month. For a single simple app you'd only need around 128MB of memory.
Pick one up, install Java (whatever Linux distro you get probably has OpenJDK in the repositories), copy your files over, and set up a cron job to run the executable at a set interval.
For easier administration, install something like webmin and use that to configure the cron job. The command would likely just be java -jar /path/to/my/App.jar, and you can use the web interface to configure the intervals for the command to be executed.
For an app like this, I would avoid anything related to a war file. You aren't making an application with a web interface (like a PHP app or some such) so it really wouldn't be appropriate. You would have to write some extra code to make it compatible with a container like Tomcat, and on top of that the memory requirements for running the application server would be a lot higher.
Problem: I have a standalone Java app (henceforth known as "the agent") that runs as a service on internal company servers. It acts as a remote agent for some central servers. As the agent gets deployed in more places, managing them is getting more complicated. Specifically: pushing updates is painful because it's a fairly manual process, and getting access to the logs and other info about the environments where the agents are running is problematic, making debugging difficult. The servers under discussion are headless and unattended, meaning that this has to be a fully automated process with no manual intervention, hence Java Web Start isn't a viable solution.
Proposed solution: Make the agent phone home (to the central servers) periodically to provide agent status and check for updates.
I'm open to other suggested solutions to the problem, but I've already got a working prototype for the "status and self-updates" idea, which is what this question is focused on.
What I came up with is actually a separate project that acts as a wrapper for the agent. The wrapper periodically calls the central server via HTTP to check for an updated version of the agent. Upon finding an update, it downloads the new version, shuts down the running agent, and starts the new one. If that seems like an odd or roundabout solution, here are a few other considerations/constraints worth noting:
When the wrapper gets a new version of the agent, there may be new JAR dependencies, meaning class path changes, meaning I probably want to spawn a separate Java process instead of fiddling with ClassLoaders and running the risk of a permanent generation memory leak, which would require manual intervention--exactly what I'm trying to get away from. This is why I ended up with a separate, "wrapper" process to manage the agent updates in my prototype.
Some servers where the agents are deployed are resource-limited, so any solution needs to be low on CPU and memory usage. That makes me want a solution that doesn't involve spinning up a new JVM and is a stroke against having a separate wrapper process.
The agent is already deployed to both Windows and RHEL servers, so the solution must be cross-platform, though I wouldn't have a problem duplicating a reasonable amount of the process in batch and bash scripts to get things rolling.
Question: As stated, I want to know how to make a self-updating Java app. More specifically, are there any frameworks/libraries out there that would help me with this? Can someone with experience in this area give me some pointers?
If your application is OSGi based, you could let OSGi handle bundle updates for you. It is similar to the wrapper approach you suggest, in that the OSGi container itself is "the wrapper" and some of it won't be updated. Here's a discussion on this
Different solution: use (and pay for) install4j. Check out the auto-update features here
No need for wrapper (save memory) or java web start (adds more restrictions on your application), simply let a thread in you application check periodically for updates (e.g. from cloud) and download updates if available, then code these two calls in you application:
launch a shell script (.sh or .cmd) to update your artifacts and launch your application after few seconds pause in the script(to avoid having two instances of your application at the same time).
Terminate your application (first instance)
The script can overwrite needed artifacts and re-launch your application.
enjoy !
Have a look at Java Web Start.
It is technology that's been part of Java since... 1.5? maybe 1.4? and allows deployment and install of standalone Java-based apps through a web browswer. It also enables you to always run the latest app.
http://www.oracle.com/technetwork/java/javase/overview-137531.html
http://en.wikipedia.org/wiki/JNLP#Java_Network_Launching_Protocol_.28JNLP.29
also see this question: What's the best way to add a self-update feature to a Java Swing application?
It appears as though Webstart is the only built in way to do this at the moment.
We've developed a small app using play!, and it runs standalone on a user's computer (Windows XP or Windows 7), as the users don't have network access. Currently, it runs within a console/command window. I would like to make it so there's no console window in the taskbar where play is running--really, mostly because the users are prone to closing the the window. I came up with a couple of ideas, but I was hoping for some validation or other ideas.
First, I was thinking of running Java via javaw, which is typically what runs for GUI applications running Java--but what would I run? I guess I could run the Winstone Servlet container with the WAR output of play! (mentioned as a solution to the other stackoverflow question below).
Second, I was thinking of trying to wrap it in a windows service.
This question is similar, but slightly different (I don't mind installing play!, which just involves unzipping the framework):
Deploy Play! application as executable jar
Has anyone used either of these techniques, or is there a better way? Pros/Cons/Examples?
Thanks!
Update: Any comments about Winstone? It turns out that due to security constraints, we'll not be able to [easily] create services or scheduled tasks (as SYSTEM). Thanks again.
I have done something similar for a few applications. The steps I carried out are
Create a bat file that launches the play app. This could be as simple as play run or play start
Create a scheduled task that executes on system startup, using SYSTEM as the user profile to run the command as.
This approach has been working on my internal systems for well over a year.
Alternatively you can use yajsw to wrap your play application as a windows service. It works really well and is easy to set up.
The only issue I have encountered is that on one of my box running on Windows Server 8 R2, some of the jobs are duplicated when the scheduler kicks off. I am not convinced it is directly related to yajws and I have not been able to reproduce the error on other environments with the same setup.
I managed to work around it by adding a synchronization block in my doJob method.
Have a look here for info for setting up yajws with play.
I am not sure if play would work on winstone. A list of application servers known to work with play can be found here.
You will need to war your play application with play war myapp -o myapp.war and test it first.
I ended up creating a batch file that runs "play run", and a runnable JAR that calls "start /B runPlay.bat" as a system call. This way, the console window doesn't start up at all. It works great so far. There seem to be a variety of solutions, but this was fairly simple.