I have created an application and now I want it to make a plugin ready. I have decided to use Apache Felix and after reading tutorial, I am not sure, whether it was a choice that I wanted to.
I want to change my application, so that it loads at the beginning Bundles from /plugins folder and adds every Bundle as a JMenuItem to JMenu. I could have done it using ClassLoader, but I thought OSGi was exactly what I wanted, but then I encountered some problems:
there is a command line for OSGi, but I need it to be implemented in my application, without any user interaction, hard code its default behaviour in code.
there is behaviour of a Bundle ( start() and stop() methods inherited from org.osgi.framework.BundleActivator) that Bundle invokes at the beginning, but I actually want my application, to do something with a Bundle, not a Bundle to do something with an application.
So could you tell me, whether it is possible to make it using OSGi (etc. Apache Felix) or should I implement it using ClassLoader and then explicitly convert a .jar plugin's Main Class to JMenuItem and add it to my JMenu (it is worse, because it doesn't support dynamic change of application and doesn't give me a chance to learn OSGi).
EDIT: I am thinking about sth like: http://karussell.wordpress.com/2009/09/16/plugable-swing-a-hello-world-osgi-example/ , but I cannot find any tutorial.
Why would you create a menu item for every bundle that exists in the view? That doesn't really make sense.
You /could/ do it by creating your GUI app, and then in the start() method, persist the context and then use that to query a list of all bundles in the system. You would probably want to do that on demand when your menu was shown (so you see a current list).
However, you're really thinking in the wrong direction. What you want to do is look for /services/. When a service comes in, you use that service to populate your menu item. That way, you can have multiple services per bundle and the services can have some form of interaction.
Neil Bartlett and myself did a talk on exactly this approach for a Swing-based application (though using registered Action objects). The demo and presentation are still available from this location:
http://www.eclipsezone.com/files/jsig/
Note that this was done at the time of OSGi v4, so you might find the install fails with a mismatched version of the import framework. If so, crack open the file and ensure that it doesn't say Import-Package: org.osgi.framework;version="[1.3.0,1.4.0)" or some such - get rid of the version numbers and it should still run fine today.
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 am doing application using Eclipse 4 rcp. I general it is single perspective UI with layout based on Part View's, what allows me to drag, and reorder layout. Problem is that it is automatically persisted.
Is it possible to handle that process? I would like to create handler which would reset my layout to stock.
I saw tutorial here: Eclipse 4 Model Persistence - Tutorial but did not catch that point:
-Should I really override ResourceHandler.
-What is required to write hadlers like in example. Because line:
E4XMIResourceFactory e4xmiResourceFactory = new E4XMIResourceFactory();
Resource resource = e4xmiResourceFactory.createResource(null);
throws compile time exception:
The type org.eclipse.emf.ecore.xmi.impl.XMIResourceFactoryImpl cannot be resolved. It is indirectly referenced from required .class files.
I maybe someone can explain or give a simple example, how to handle basic persistence of layout. Or at least hot to revert it to such, which was programmed
Include the plugin org.eclipse.emf.ecore.xmi in your plug-in's dependencies to resolve XMIResourceFactoryImpl (and org.eclipse.emf.ecore for Resource)
The author of this tutorial is one of the main Eclipse developers and his tutorials are usually accurate.
If you just want your application to always start with the original layout you can specify the -clearPersistedState option in the program arguments in your xxx.product file. You can also use -persistState false to stop the persistence of the model altogether.
Say that we are writing a Java Swing application and we use Eclipse or MyEclipse to develop it. In web applications, you make code changes, you save and your ant deployment file takes care of the deployment of the changed files. Then you just refresh or hard refresh the web page and the changes appear there. Can we do the same thing for a Swing applications so that we don't have to close and open the program from the beginning every time we make a change?
I don't think so because you need hot code replacement ! Maybee using another framework.
You can't simply do that because once JVM is started, it loads the class files once and will not reload it untill next loading request. But you can use ClassLoader to load modified class files dynamically.
The following two articles may help:
IBM article on "hot class swap"
"Who Said Runtime Class Reloading Is Hard in Java?"
The first one is in Chinese, but you can look at the code and the result. I think the second article is more helpful for a GUI application.
In MyEclipse you can start your application in debug mode instead of run mode and changes you make will be pushed to the target VM; if changes you make cannot be replaced you'll see a dialog informing you the replace failed and you will need to restart your application. You don't need to place any breakpoints in the application, just starting in debug mode is sufficient.
As Guillaume states above, changes to the class structure will typically not be hot-synched, but changes within existing methods should be fine.
Obviously, how successfully hot-synched changes affect your running application would depend on your application design.
I'm creating a Win32 application that controls another application which is coded in Java using AWT components. I figured that if I can retrieve the main List of the application and cast it with the JLIB library I'd be able to read its content.
First of all, am I right or I won't be able to get the real content of the List ? If I'm right I'd like to know how to achieve this since I didn't found any good spy software for Java and Spy++ only show a SunAwtComponent. Which I presume in the container for the whole Java application.
I'm not expecting someone to tell me how to do the whole thing but only a couple of direction would be really great since I've been looking for that for a while now.
Thanks for the replies !!!
Quite likely the Java application actually uses Swing, not AWT. Swing draws its own widgets on top of a single AWTComponent, so the list widget that you see doesn't exist from Windows point of view.
I assume you cannot modify this Java application so that it can be controlled over some reasonable API (e.g. JMX or REST)?
You can try running the JVM with JPDA debugging interface enabled. You can then use JPDA APIs to change data structures and directly call methods on any object in that program. Finding the right ones to call will be hard, though.
See http://download.oracle.com/javase/6/docs/jdk/api/jpda/jdi/index.html
I am currently working on desktop software based on java.It's quite a big code base (more than 40 jar files).
I wish to provide an automatic update functionality. The desktop software constantly checks one back end system to see if there are new versions of the jar files available.
The problem now is: How to replace the updated jar files?
If you deploy your application using Java Webstart (JNLP), you get this mechanism almost for free...
From http://mindprod.com/jgloss/javawebstart.html
The key benefit for Java Web Start is automatic update without having to download the entire program every time.
Easiest would be to check for updates on each startup, download the updates and then launch your application. I think this is the way that Java Web Start works (see aioobes answer).
More complex would be to use either the netbeans or eclipse framework for your application. Both are rather complex and you will have to rewrite your application to work with them. This solution supports live updates.
As far as I am aware there is no easy way to update a running application. It is possible to load new versions of a class with a different classloader, but not possible to unload old versions while they are still referenced.
You can make a little server and a launcher which downloads the newest version, replaces the old one, and starts the jar with:
Runtime.getRuntime().exec("java yourjar -jar");
And you terminate the launcher with:
System.exit(1)
You can also serialize down your state (keep it in memory) and then create a new ClassLoader instance pointing to the new .jar files. Then serialize up your state again using this new classloader. You have just changed the underlaying .jars within a executing product.
Please note that you do not need to change the classloader for everything only for the part that is actually using the .jar files. This can be tricky to conclude what parts that are. And you might get nasty linking errors if done wrongly. So..
.. to keep it simple, use WebStart or a preloader that updates the .jars and then starts the main app (basically what WebStart does for you).
A reason for rolling your own, is that you can use your own format for the .jars, encryption, other packing formats etc.
After reading some answers to many auto-update questions, I thought of a solution. This is how I would implement a secure auto-update for a Java/Kotlin jar application.
Assumption: the installer will contain two jars: a launcher and the main application. Any shortcuts created will point to the launcher, but still be the name of the application. The release will contain the main application and the installer.
The launcher is launched first:
First check if an update has already been downloaded as app_name_update.jar
if an update has been downloaded, rename app_name_update.jar to app_name.jar
Start app_name.jar
This part does not have to be in the launcher, but it's preferred as to not slow down the main application: at this point, the launcher should check for an update (e.g. GitHub releases API) and download it to {CWD}/unverified_app_name_update.jar.
Compare the hash of unverified_app_name_update.jar to an online location containing hashes for all published versions. hashes.txt would be an example found in the same github repository. If the software is open-source, GPG signed commits is a must and the launcher should check if the latest update is a verified commit! If its a proprietary application, keep the hashes.txt at a separate URL from the release where your company does not control the infrastructure (e.g. GitHub).
Main app launched:
No need to check for updates unless updates are mandatory, in which case check for update -> if update found, start loading animation "updating" while you can detect that the launcher is still running. Ensure that the launcher has no race condition while loops!
I found ready project to solve automatically updating.
You can update your app, in your cases you can update jars and resources of your desktop app. The idea of the this is next: wrap you app with starter which can control updating and running you app. In details you can find here.