wood burning stoves 2.0*
The moose likes Java in General and the fly likes Patching Java applications without restarting application Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Patching Java applications without restarting application" Watch "Patching Java applications without restarting application" New topic
Author

Patching Java applications without restarting application

Serkan Demir
Ranch Hand

Joined: Feb 03, 2005
Posts: 61
Hi guys,
Assume that i have an application which needs future patches. Whenever a patch is prepared, i have put this patch into a directory which is pointed in the classpath. The patch will include new versions of existent classes with the same name. The position of this patch is in front of the main application jar in the classpath. So newly created objects will be instantiated from patch without reset application(i am right,aren't i? ). But i am wondering about old objects which is created before patches. If i can customize Classloader, might it be possible to make a runtime patching system which also patches old objects without restarting application ?
Do you know any kind of patching techniques?

thanks lot,

Serkan Demir


A guy from Turkey<br /><a href="http://blogspot.serkandemir.com" target="_blank" rel="nofollow">http://blogspot.serkandemir.com</a>
pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547
So newly created objects will be instantiated from patch without reset application

Probably not. The classloader loads the the class definition and then caches it. So it will not reload the class definition (unless you provide your own loader).

might it be possible to make a runtime patching system

Again...probably not (unless you patch the JVM)

pascal
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

This can be partially done. The general strategy is this: (1) Have your significant objects loaded by your own classloader (a URLClassLoader would work); (2) When creating a significant object, always create a new classloader to load it (or create a new classloader if the jar file where the classes are located has changed).

You are not likely able to do anything about objects that already exist in your JVM.
Adam Nace
Ranch Hand

Joined: Jul 17, 2006
Posts: 117
Originally posted by Paul Clapham:
You are not likely able to do anything about objects that already exist in your JVM.


Actually, there is a solution to this, too, but it has some definite overhead associated with it. You COULD make a pool of all of your objects of each given class that might be patched (i.e. have the constructor register itself with a collection of Weak References). Furthermore, make all of your classes act through proxies, so that all other objects see is the proxy. Also, provide a copy constructor that is compatable with old versions of the class. Then you can use the collection to obtain a reference to all of the proxies, get the objects contained by them, copy them into new instances of your repaired class, and replace the obect referred to by each proxy with the new version.

Of course, it's easier said then done, and it has a LOT of overhead, but I'm pretty sure it could be done.

- Adam
Serkan Demir
Ranch Hand

Joined: Feb 03, 2005
Posts: 61
I have found this paper.
http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf
There is a good technique explained. A Server class has a Service reference which is highly probable to change. He defined Service as an interface and whenever a patch is needed for Service, he puts the patch into a specific directory and call updateService method.



class Server {
private Servicelnterface service; // use an interface
public void updateService(String location) {
MyClassLoader cl = new MyClassLoader(location);
Class c = cl.loadClass(�Service�);
service = (Servicelnterface)c.newlnstance();
}
public void processRequest (,..) {
service.run(...);
pascal betz
Ranch Hand

Joined: Jun 19, 2001
Posts: 547
the service/server thing could work (i think it's about the same as the proxy solution Adam mentioned). it's easier if the classes which should be swapped are (stateless) services, there are often instantiated in one place and there is no need to transfer state from the old service to the new one. but if you need to swap other objects (e.g. domain objects like "Person", "Schedule" or whatever) because the places where they are instantiated are usualy all over the code base.

another thought: if you have this copy constructor as described in Adams post, then you probably need to apply all the updates in a specific order (from version 1 to version 2 to version 3) because version 3 might depend on state that exists in version 2 but not in version 1 ???

pascal
Serkan Demir
Ranch Hand

Joined: Feb 03, 2005
Posts: 61
you are right Pascal, i think this discussion goes towards a need for a container similar to Spring or EJB.
It is possible to change stateless objects but it is hard to change domain objects. (this remembers me entity and session beans in EJB).
Another question to whom spends time with JMX and manageble objects; I am not familiar with JMX very much but i have known that all objects which implement an interface with a suffix MBean are manageable. Is it possible to inject new objects (but domain stateful domain objects) or change the existent ones via JMX?
 
Don't get me started about those stupid light bulbs.
 
subject: Patching Java applications without restarting application
 
Similar Threads
Windows Native Jar Equivalent Tool
IE Randomly just closes
svn list command does not work
Patching an EAR and the like
Error loading jpeg