weblogic.Deployer fails to redeploy application

0
votes

I'm working out deployments to a Weblogic 12c (v12.1.1) server and I'm running into this exception when I attempt to redeploy and updated ear:

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)

If I remove the one TimedObject I found from the ear it'll redeploy fine. This is older code with 2.x EJBs. Was this a known issue that has been resolved in more recent versions of Weblogic? I have yet to find documentation of this issue.

Thanks in advance!

New Info:

Turns out the ejb code is compiled as 3.1 according the the maven-compiler-plugin ejbVersion in the project's pom file. I tried using @Schedule annotation to see if making the timer an Automatic timer would affect redeployment but so far no luck... same exception as noted above.

Here is how I'm doing my initial deploy:

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

Here is how I'm doing my redeploy after rebuilding the app and updating the ear's version in it's MANIFEST:

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

After the exception if I use weblogic.Deployer's -listapps option I will see both applications listed with the earlier version shown as active and the update version as inactive. I can undeploy either or both of the active or inactive apps without error. With both inactive and active versions undeployed I can then deploy the updated app without error. It is only during the redeploy that the exception is thrown.

This sort of redeploy works for other applications that don't have an EJB timer as in my problem archive.

Another update:

As suggested, I tested using the same value for the -source option like so:

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

Rebuilt the app and updated the ear's version in it's MANIFEST:

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

Fails w/ same Exception for the ear with the EJB timer and works fine for app w/o the EJB timer.

1
ejb-3.1weblogic12cejb-2.x
The error doesn't happen on the first deploy? Or you're updating using a completely new version of EJB? The question is confusing. Are you following an example like: blogs.oracle.com/jamesbayer/entry/… – Display Name is missing
The error doesn't occur on the first deploy. The scenario is like so: build ear and deploy, build a new version of ear and redeploy. The redeploy fails with the exception shown above. – user1052313
How are you running the redeploy? Via the admin console? Are you issuing an update from weblogic.deployer? If you try to stop or delete the original .ear from the admin console does it also throw errors in the log (without trying to redeploy)? – Display Name is missing
And you're updating the app version in the MANIFEST of the .ear file? Note: Do not specify the redeploy -source option for non-versioned applications or existing versioned applications if the source location has changed. In those cases, you must first undeploy, then deploy the application. In your case, the source location IS changing since the file name changed – Display Name is missing
Yes, the app's version is updated in the MANIFEST.MF. – user1052313

1 Answers

0
votes

Not so much an answer for the root cause but a viable workaround for my particular use case...

The problem EAR contained only one EJB that implemented TimedObject. I removed the Timer elements of the EJB and modified an existing class that provided a main to activate/deactivate the timed object. I modified the class to simply execute the important processing method(s) of the previously timed object. I can schedule invoking that from cron.