weblogic.Deployer не может повторно развернуть приложение

Я разрабатываю развертывание на сервере Weblogic 12c (v12.1.1), и я сталкиваюсь с этим исключением, когда пытаюсь повторно развернуть и обновить ухо:

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 из уха, он развернется заново. Это более старый код с EJB 2.x. Была ли это известная проблема, которая была решена в более поздних версиях Weblogic? Мне еще предстоит найти документацию по этой проблеме.

Заранее спасибо!

Новая информация:

Оказывается, код ejb скомпилирован как 3.1 в соответствии с maven-compiler-plugin ejbVersion в pom-файле проекта. Я попытался использовать аннотацию @Schedule, чтобы увидеть, повлияет ли создание таймера на автоматический таймер на повторное развертывание, но пока не повезло ... такое же исключение, как указано выше.

Вот как я делаю свое первоначальное развертывание:

java weblogic.Deployer -adminurl t3: // localhost: 7001 -username xxxxxxxx -password xxxxxxxx -deploy -name wjade -source /tmp/onesystem-app-2.0-SNAPSHOT-20141202152000.ear

Вот как я делаю повторное развертывание после пересборки приложения и обновления версии уха в МАНИФЕСТЕ:

java weblogic.Deployer -adminurl t3: // localhost: 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: // localhost: 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 -password xxxxxxxx -redeploy -name wjade -source /tmp/onesystem-app-2.0-SNAPSHOT.ear

Не работает с тем же исключением для уха с таймером EJB и отлично работает для приложений без таймера EJB.