Trying unsuccessfully to redeploy an older ear on WLS9.2

Question

Hi All,
I've spent a few days trying to get a redeploy of an ear working on WLS9.2 using the wldeploy ant task. It works where the ear file is newer that the one already deployed, but redeploy just doesn't take effect if the ear we want is older than the one that is already deployed. It doesn't give an error, the log says that it's redeployed, but the redeploy doesn't take effect. This wldeploy task worked fine with WLS8.1 no matter when the ear was built.
It seems to be the same issue as
http://forums.bea.com/bea/thread.jspa?forumID=2033&threadID=400002694&messageID=400007471#400007471
I'm out of ideas, so any help would be gratefully received!
The original deployment via the console was fine, specifying DDOnly. The ear was loaded from the location C:\EARS\app.ear on the machine "host1" We then specified that the location from which the ear would be available would be \\host1\ears\app.ear which is the same location simply specified as a network drive.
An Ant task, not the wldeploy task, copies the ear we want from any development machine to the networked host1 location. This step works fine.
Then we try to redeploy using the wldeploy task. This only seems to work if the ear file we're trying to deploy is newer than the one we already had running.
The task was as follows, with all options valid and one target server specified in targets:
          <wldeploy action="redeploy"
               source="${source}"
               name="${appname}"
               user="${user}"
               password="${pass}"
               verbose="true"
               adminurl="${adminurl}"
               debug="true"
               targets="${targets}">
          </wldeploy>
Source is specified as \\host1\ears\app.ear
Since then, we've been changing all kinds of options in wldeploy trying to get it to work for older ears, but it won't.
extract from one of many log files showing wldeploy logging for an older ear. In this case, we're trying to replace deployed version built at 10:30 with version built at 10:22. It shows successful but the version from 10:30 is still deployed on the managed server ManagedServer1 after the redeploy. The task is:
          <wldeploy action="redeploy"
               retiretimeout="1"
               source="${source}"
               name="${appname}"
               user="${user}"
               password="${pass}"
               verbose="true"
               adminurl="${adminurl}"
               debug="true"
               graceful="false"
               targets="${targets}">
          </wldeploy>
copy_ear:
[delete] Deleting 1 files from \\HOST1\EARS
[copy] Copying 1 file to \\HOST1\EARS
weblogic_redeploy:
[echo] message="ant wldeploy classpath is: /bea/weblogic92/server/lib/weblogic.jar"
[wldeploy] weblogic.Deployer -debug -verbose -noexit -name app1 -source \\host1\ears\app.ear -targets ManagedServer1 -adminurl t3://host1:5001 -user weblogic -password ******** -redeploy -retiretimeout 1
[wldeploy] weblogic.Deployer invoked with options: -debug -verbose -noexit -name app1 -source \\host1\ears\app.ear -targets ManagedServer1 -adminurl t3://host1:5001 -user weblogic -redeploy -retiretimeout 1
[wldeploy] [WebLogicDeploymentManagerImpl.<init>():103] : Constructing DeploymentManager for J2EE version V1_4 deployments
[wldeploy] [WebLogicDeploymentManagerImpl.getNewConnection():146] : Connecting to admin server at host1:5001, as user weblogic
[wldeploy] [ServerConnectionImpl.getEnvironment():288] : setting environment
[wldeploy] [ServerConnectionImpl.getEnvironment():291] : getting context using t3://host1:5001
[wldeploy] [ServerConnectionImpl.getMBeanServer():239] : Connecting to MBeanServer at service:jmx:t3://host1:5001/jndi/weblogic.management.mbeanservers.domainruntime
[wldeploy] [ServerConnectionImpl.getMBeanServer():239] : Connecting to MBeanServer at service:jmx:t3://host1:5001/jndi/weblogic.management.mbeanservers.runtime
[wldeploy] [DomainManager.resetDomain():36] : Getting new domain
[wldeploy] [DomainManager.resetDomain():39] : Using pending domain: false
[wldeploy] [MBeanCache.addNotificationListener():96] : Adding notification listener for weblogic.deploy.api.spi.deploy.mbeans.TargetCache@40ece0
[wldeploy] [MBeanCache.addNotificationListener():103] : Added notification listener for weblogic.deploy.api.spi.deploy.mbeans.TargetCache@40ece0
[wldeploy] [MBeanCache.addNotificationListener():96] : Adding notification listener for weblogic.deploy.api.spi.deploy.mbeans.ModuleCache@1954f89
[wldeploy] [MBeanCache.addNotificationListener():103] : Added notification listener for weblogic.deploy.api.spi.deploy.mbeans.ModuleCache@1954f89
[wldeploy] [ServerConnectionImpl.initialize():171] : Connected to WLS domain: OGPDomain
[wldeploy] [ServerConnectionImpl.init():161] : Initializing ServerConnection : [email protected]e9
[wldeploy] [BasicOperation.dumpTmids():690] : Incoming tmids:
[wldeploy] [BasicOperation.dumpTmids():692] : {Target=ManagedServer1, WebLogicTargetType=server, Name=app1}, targeted=true
[wldeploy] [RedeployOperation.setupPaths():86] : in place redeploy: false from moduleArchive: \\host1\ears\app.ear
[wldeploy] [RedeployOperation.setupPaths():95] : redeploy src path: \\host1\ears\app.ear
[wldeploy] [BasicOperation.deriveAppName():139] : appname established as: app1
[wldeploy] <08-Aug-2007 10:18:00 o'clock IST> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating redeploy operation for application, app1 [archive: \\host1\ears\app.ear], to ManagedServer1 .>
[wldeploy] [BasicOperation.dumpTmids():690] : Incoming tmids:
[wldeploy] [BasicOperation.dumpTmids():692] : {Target=ManagedServer1, WebLogicTargetType=server, Name=app1}, targeted=true
[wldeploy] [BasicOperation.loadGeneralOptions():607] : Delete Files:false
[wldeploy] Timeout :3600000
[wldeploy] Targets:
[wldeploy] ManagedServer1
[wldeploy] ModuleTargets={}
[wldeploy] SubModuleTargets={}
[wldeploy] }
[wldeploy] Files:
[wldeploy] null
[wldeploy] Deployment Plan: null
[wldeploy] App root: C:\dev\RELEASE\config\deployments\conord\app1
[wldeploy] App config: C:\dev\RELEASE\config\deployments\conord\app1\plan
[wldeploy] Deployment Options: {isRetireGracefully=false,isGracefulProductionToAdmin=false,isGracefulIgnoreSessions=false,rmiGracePeriod=-1,retireTimeoutSecs=1,undeployAllVersions=false,archiveVersion=null,planVersion=null,isLibrary=false,libSpecVersion=null,libImplVersion=null,stageMode=null,clusterTimeout=3600000,altDD=null,altWlsDD=null,name=app1,securityModel=null,securityValidationEnabled=false,versionIdentifier=null,isTestMode=false,forceUndeployTimeout=0,defaultSubmoduleTargets=true,timeout=0}
[wldeploy] [BasicOperation.execute():424] : Initiating redeploy operation for app, app1, on targets:
[wldeploy] [BasicOperation.execute():426] : ManagedServer1
[wldeploy] [RedeployOperation.initializeTask():55] : Starting task with path: \\host1\ears\app.ear
[wldeploy] Task 69 initiated: [Deployer:149026]deploy application app1 on ManagedServer1.
[wldeploy] Task 69 completed: [Deployer:149026]deploy application app1 on ManagedServer1.
[wldeploy] Target state: redeploy completed on Server ManagedServer1
[wldeploy]
[wldeploy] [ServerConnectionImpl.close():334] : Closing DM connection
[wldeploy] [ServerConnectionImpl.close():354] : Unregistered all listeners
[wldeploy] [ServerConnectionImpl.closeJMX():374] : Closed JMX connection
[wldeploy] [ServerConnectionImpl.closeJMX():386] : Closed Runtime JMX connection
[wldeploy] [ServerConnectionImpl.closeJMX():398] : Closed Edit JMX connection
install_app:
install_app:
BUILD SUCCESSFUL
Total time: 21 seconds
Thanks for your time,
ConorD

Answer 1

Daniel Greeney wrote:
So I just purchased an internal drive (separate from my system drive) to use as a Time Machine drive, for both of my computers (only one partition). Since they will be backing up every day, I will retain much more recent material in case of drive failure.
Let Time Machine back up every hour, as it's designed. That will protect you best.
My question is this - if I have a drive failure on my current internal system drive, and the internal Time Machine is intact, is it possible for me to take my external bootable backup (say 3 weeks older than Time Machine in how recently it was backed up), make a cone of that on a new internal system drive, and then use Time Machine to restore that drive to what is most current on Time Machine?
Does this question make sense?
The question makes sense until you realize that Time Machine backups contain everything you need (unless you do something silly, like exclude your system files).
Once the new drive is installed and formatted, you can restore your entire system from the TM backups faster than you can copy the clone to the new internal HD. See #14 in the Frequently Asked Questions *User Tip,* also at the top of this forum. Note that you use the Snow Leopard Install disc only for the Installer on it; you don't install OSX from it.