我工作了部署到WebLogic 12C（v12.1.1）服務器，我遇到了此異常，當我嘗試重新部署和更新的耳朵：的weblogic.Deployer未能重新部署應用
Task 5 initiated: [Deployer:149026]deploy application wjade [Version=2.0-SNAPSHOT-20141201135918] on AdminServer.
Task 5 failed: [Deployer:149026]deploy application wjade [Version=2.0-SNAPSHOT-20141201135918] on AdminServer.
Target state: redeploy failed on Server AdminServer
java.lang.NullPointerException
java.lang.NullPointerException
at weblogic.ejb.container.timer.EJBTimerManager.undeploy(EJBTimerManager.java:386)
at weblogic.ejb.container.manager.BaseEJBManager.undeployTimerManager(BaseEJBManager.java:429)
at weblogic.ejb.container.manager.BaseEJBManager.undeploy(BaseEJBManager.java:411)
at weblogic.ejb.container.manager.StatelessManager.undeploy(StatelessManager.java:384)
at weblogic.ejb.container.deployer.EJBDeployer.deactivate(EJBDeployer.java:1489)
at weblogic.ejb.container.deployer.EJBModule.doDeactivate(EJBModule.java:1020)
at weblogic.ejb.container.deployer.EJBModule.activate(EJBModule.java:477)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:192)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:187)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:58)
at weblogic.application.internal.flow.ScopedModuleDriver.activate(ScopedModuleDriver.java:206)
at weblogic.application.internal.ExtensibleModuleWrapper.activate(ExtensibleModuleWrapper.java:97)
at weblogic.application.internal.flow.ModuleListenerInvoker.activate(ModuleListenerInvoker.java:114)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:192)
at weblogic.application.internal.flow.ModuleStateDriver$2.next(ModuleStateDriver.java:187)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
at weblogic.application.internal.flow.ModuleStateDriver.activate(ModuleStateDriver.java:58)
at weblogic.application.internal.flow.DeploymentCallbackFlow.activate(DeploymentCallbackFlow.java:145)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:582)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:148)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:114)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:335)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
如果我刪除從耳朵中找到的一個TimedObject，它將重新部署。這是使用2.x EJB的舊代碼。這是一個在更新版本的Weblogic中已經解決的已知問題嗎？我還沒有找到這個問題的文件。
在此先感謝！
新信息：
原來EJB代碼是根據項目的POM文件中的行家，編譯器插件ejbVersion編譯爲3.1。我試圖使用@Schedule註釋來查看是否使計時器成爲自動計時器會影響重新部署，但到目前爲止沒有運氣......與上面提到的相同的例外情況。
這裏是我正在做我的初步部署：
的java的weblogic.Deployer -adminurl T3：//本地主機：7001 -username XXXXXXXX -password XXXXXXXX -deploy -name wjade -source的/ tmp/onesystem- APP-2.0-快照20141202152000.ear
這裏是我如何重建應用程序和更新耳朵的版本，在它的清單後做我的重新部署：
的java的weblogic.Deployer -adminurl T3：//本地主機：7001 -username xxxxxxxx -password xxxxxxxx -redeploy -name wjade -source /tmp/onesystem-app-2.0-SNAPSHOT-20141202152232.ear
如果我使用weblogic.Deployer的-listapps選項，則會看到兩個應用程序，其中早期版本顯示爲活動狀態，更新版本爲非活動狀態。我可以毫無錯誤地取消部署或啓用活動或非活動應用程序。在未啓用的和未啓用的版本中，我可以部署更新的應用程序而不出錯。只有在重新部署期間拋出異常。
這種重新部署適用於沒有EJB定時器的其他應用程序，與我的問題歸檔中一樣。
另一個更新：
如所建議的，我測試使用-source選項像這樣的值相同：
的java的weblogic.Deployer -adminurl T3：//本地主機：7001 -username XXXXXXXX -password XXXXXXXX -deploy -name wjade -source /tmp/onesystem-app-2.0-SNAPSHOT.ear
重建應用程序，並更新了耳朵的版本，在它的清單：
的java的weblogic.Deployer -adminurl T3：// localhost：7001 -username xxxxxxxx -passwo rd xxxxxxxx -redeploy -name wjade -source /tmp/onesystem-app-2.0-SNAPSHOT.ear
失敗w /與EJB定時器相同的異常，並且適用於不帶EJB定時器的應用程序。
該錯誤不會在第一次部署時發生？或者您正在使用全新版本的EJB進行更新？問題很混亂。您是否按照以下示例進行操作：https://blogs.oracle.com/jamesbayer/entry/a_simple_job_scheduler_example – 2014-12-02 19:02:18
第一次部署時不會發生該錯誤。該方案如下所示：構建耳朵並部署，構建新版本並重新部署。重新部署失敗，出現上述例外情況。 – user1052313 2014-12-02 21:18:15
你如何運行重新部署？通過管理控制檯？你是否從'weblogic.deployer'發佈'update'？如果您嘗試從管理控制檯中停止或刪除原始.ear，它是否也會在日誌中引發錯誤（無需重新部署）？ – 2014-12-02 21:32:06