This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
We developed a translation tool, functionality of tool is when we given the input file to our tool depends on the map rule it will generate the output file, but eventually we modified the source codes to meet the requirements and performance optimization. So we are using different version of source codes for different version of map files. Still in production we are using the old source code. As of now we cannot use the updated source code in production. So incorporating the update source code changes in production We decided use a controller class do decide which version of jar files will be executed depends on a map file version no. Please guide me how I can implement this, please provide me your valuable suggestion or give me any use full link to help me to solve this problem.
Instead of packaging the two code bases as two jar files, I would structure it so that there is only code base, which decides at runtime which of the two algorithms it is going to use. The decision could be based on an init parameter, user input, configuration file, or something similar.
1) you have an old, functioning code running in production 2) you have a new, updated code which at some point in the future will replace the old code
I don't see why you need to do anything at all - it is not required that the two versions should be running in production at the same time, as far as I can see.
Maybe I'm missing something. My understanding is that you want two different versions of the same class (call it com.mycompany.TranslationTool) to run in the same application at the same time. Why not change version of the jar file when it is ready to use the new version?
Take a look at the Strategy design pattern. That's exactly the kind of scenario polymorphism was invented for!
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Apr 18, 2006
thnaks for the prompt reply.
�dne, we can't use the new version of jar file in production coz the input file for this trasilation tool, we used to call it as map file (tranilation rules) is older version that will run only older version source code, but the new map file will run only in updated code. we don't have the control to modify the map file that is already in production. so we need to run the both jar file in production. but this jar file contains different verion of same source code.
None of those ideas address "different version of the SAME source", which I'm reading to mean the same package and class name. There is great potential for confusion and other problems but you might be able to deploy both version1.jar and version2.jar. Don't put either in the classpath for the JVM but work with class loaders that have one jar or the other in their extended classpaths. That makes me shudder just talking about it.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Mar 22, 2005
**Shudder** indeed. But since it's software developed in-house, the source is available. So it would be easy to change the package names on one of the versions, and then follow the previous suggestions.
Joined: Jan 29, 2003
Part of the normal development practice from this time forward is including the release number somewhere in the package hierarchy? Yikes again?
you may use a custom classloader,you may have 2 classloaders one loading the old version and other loading the new.Then you may choose which classloader to use the class hierarchy
hope this helps
Joined: Jul 11, 2001
It's probably possible to solve this problem using classloaders or something. I'd fear that as a road to maintenance hell, though. It would probably be much easier to restructure the code to have it select the appropriate Strategy object or something at runtime.