Redeploying libraries in iterative development
By aseembajaj on Aug 12, 2009
Deployment command and tools deal with libraries in the same way as applications. The same set of commands are supported for libraries as for applications. There are, however, additional restrictions on library undeployment and redeployment. Undeployment or redeployment of a library is disallowed in case there are any deployed applications that refer to it in a running server. This does not necessarily interfere with upgrade scenarios. The recommended practice for upgrading shared libraries is to use versions and not to use "exact-match" while referring to libraries. A new version of library may be deployed without touching the older version. The applications that need to be upgraded may then simply be redeployed.
There is, however, a need for developers who create these libraries to test a change in deployed libraries in an iterative development scenario. If the developer does not mind loosing application state, she could use getReferencingRuntimes() methods of LibraryRuntimeMBean to identify referring applications and perform the following steps:
- Undeploy referring applications
- Redeploy library
- Deploy applications from the list gathered in #1
Here is a simple function that implements steps 1 - 3:
for app in apps:
appId = app.getApplicationIdentifier()
appPaths[appId] = cmo.getAbsoluteSourcePath()
for appId in appPaths.keys():
Such a function may then be used in WLST scripts:
if (len(sys.argv) < 4):
print "Usage java weblogic.WLST redeployLib.py [username] [password] [library-name]"
(Picture licensed from quapan under Creative Commons)