Temporary Override changes
Is there a way to setup a directory in the classpath, so that any jar files in that directory are looked at. Or do we have to list each jar file individually.
If I coluld setup a directory I would add d:\logs\abc\templib to the beginning of the classpath for all app/db/hst servers. If I have to do it individually I would like to add d:\logs\abc\templib\ArcTem
What I would like to be able to do is if there's a problem in a program like our Analyzer, we could export the fix to ArcTemp.jar instead of ArcAnalyzer.jar and put that file in the \logs\aul\templib. This would allow the new code to work until we go through the process of creating tickets and getting it deployed to our production libarary.
If I coluld setup a directory I would add d:\logs\abc\templib to the beginning of the classpath for all app/db/hst servers. If I have to do it individually I would like to add d:\logs\abc\templib\ArcTem
What I would like to be able to do is if there's a problem in a program like our Analyzer, we could export the fix to ArcTemp.jar instead of ArcAnalyzer.jar and put that file in the \logs\aul\templib. This would allow the new code to work until we go through the process of creating tickets and getting it deployed to our production libarary.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well kind of...
Basically we want a temp overide library... so for example we have a class say like "CheckThis.java" and we first migrate it to production.
Now it running and we have a problem within it..
We now want a way to move a temporary fix to a temp library and when the application is running notice its has a new copy in the temp directory with the fix and begin using this until we go through the procedures of moving it to a production.
So basically its a emergency fix solution....
Basically we want a temp overide library... so for example we have a class say like "CheckThis.java" and we first migrate it to production.
Now it running and we have a problem within it..
We now want a way to move a temporary fix to a temp library and when the application is running notice its has a new copy in the temp directory with the fix and begin using this until we go through the procedures of moving it to a production.
So basically its a emergency fix solution....
you cannot realy do that. If a class has been loaded, it will not be reloaded by the same class loader. In order to changed the implementation of a class at runtime, you must use custom class loaders. If your class is loaded by the app class loader, you're stuck with it.
You will have to be very very carefuly if you delve into this. If you have two definitions for a class, you will not be able to use one in place of the other. They will not be seen by the compiler as being the same class, though they have the same class name. Classes are compared by java by their refference (==), not by using the equals function.
You will have to be very very carefuly if you delve into this. If you have two definitions for a class, you will not be able to use one in place of the other. They will not be seen by the compiler as being the same class, though they have the same class name. Classes are compared by java by their refference (==), not by using the equals function.
ASKER
So is there a way to say instead we stop the the application and then it sees the class in the temp class file and uses that one instead of the existing one?
So this would be more like a override area, so when the classloader starts it first checks library a, and if it there it compiles that code, and bypasses not compling the current production class.... so in theory their would only be one class created...
So this would be more like a override area, so when the classloader starts it first checks library a, and if it there it compiles that code, and bypasses not compling the current production class.... so in theory their would only be one class created...
yes, there is a way. But it is dangerous (to be read: it should be handled with much care). If you do things right, you will have no problems. The main thing that increases complexity is the number of entry points in the jar(s). If there would be only one entry point (one class that knows itself about the others in the same jar), things would be quite easy.
So, instead of loading the classes from the app class loader, load them in a custom class loader, and use them. When you want to change classes, load the new classes and loose ANY reference to the old classes. If you keep references to the old classes together with the new ones, you could find yourself in quick sands.
So, instead of loading the classes from the app class loader, load them in a custom class loader, and use them. When you want to change classes, load the new classes and loose ANY reference to the old classes. If you keep references to the old classes together with the new ones, you could find yourself in quick sands.
> So is there a way to say instead we stop the the application and then it sees the class in the temp class file and uses that one instead of the existing one?
You will have to write your own classloader that will first be checking the temp folder. If the class is there then it will be loaded otherwise the application classloader will load it from the usual location.
You will have to write your own classloader that will first be checking the temp folder. If the class is there then it will be loaded otherwise the application classloader will load it from the usual location.
:)
;JOOP!