JBeret WildFly extension cannot handle runtime-name

[cornhoolio22]

Hello,

I experienced a NullPointerException, when I use a runtime-name for a batch job. I tried it with the nightly build from Friday the 11th of November.

Steps to reproduce the error:

I used the javaee7-samples

git clone git clone https://github.com/javaee-samples/javaee7-samples.git
cd javaee7-samples/util && mvn clean install
cd ../test-utils && mvn clean install
cd .. && mvn clean install --projects .
cd batch/chunk-csv-database/ && mvn clean package -DskipTests=true

Then I deployed with

deploy javaee7-samples/batch/chunk-csv-database/target/batch-chunk-csv-database.war --runtime-name=some-other-name.war

The CLI command causing the error:

/deployment=batch-chunk-csv-database.war/subsystem=batch-jberet/job=myJob:read-resource(include-runtime=true)

The stacktrace

ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 13) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("deployment" => "batch-chunk-csv-database.war"),
    ("subsystem" => "batch-jberet"),
    ("job" => "myJob")
]): java.lang.NullPointerException
    at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:68)
    at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
    at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
    at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
    at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:988)
    at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
    at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
    at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
    at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
    at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
    at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
    at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
    at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
    at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
    at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
    at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
    at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
    at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)

The problem here is also reproduceable when opening the deployments in the HTTP-Management Interface. So it is not possible anymore to open  http://localhost:9990/console/App.html#standalone-deployments .

Hi hope I got the correct forum here for my post.

So my questions here are: Are runtime-names for deployments containing batch jobs supported? And is there a workaround to use them anyway?

Thx in advance for any helpful hint.

Best Regards,

Markus

[jaikiran]

That NullPointerException does look like a genuine bug, so something that you can report in the - JBoss Issue Tracker .

The problem here is also reproduceable when opening the deployments in the HTTP-Management Interface. So it is not possible anymore to open  http://localhost:9990/console/App.html#standalone-deployments .

As for this, are you saying that because of that deployment failure, you can no longer able to view/load that page? Can you paste a screenshot of what you mean / how it looks?

[cornhoolio22]

Alright, added an issue. I put it into WildFly because its an extension. Hope this is the correct place.

And I added the picture there:

[WFLY-7570] JBeret WildFly extension cannot handle runtime-name - JBoss Issue Tracker

Cheers,

Markus

[jaikiran]

That JIRA is at the right place.

As for this:

The problem here is also reproduceable when opening the deployments in the HTTP-Management Interface. So it is not possible anymore to open  http://localhost:9990/console/App.html#standalone-deployments .

Are you saying that because of that deployment failure, you can no longer able to view/load that page? Can you paste a screenshot of what you mean / how it looks?

I looked at the image you attached to that JIRA https://issues.jboss.org/secure/attachment/12412604/error.png  and I'm not sure if that's how it supposed to show up that admin console page when there are no deployments or whether this page did end up with problems with rendering. If it did end up with a rendering problem that appears to be a separate issue in itself, something that the admin console UI team might be able to look at - maybe harald.pehl would know more.

[cornhoolio22]

I have 2 deployments in my WildFly. One should work and one is the broken one.

Loading the deployments throws the exception from the initial post and no deployment is shown at all.

I haven't looked into the code of the UI, but it seems to show no deployments if there are problems getting information about one deployment.

[harald.pehl]

The deployments are read in the console using the operation :read-children-resources(child-type=deployment). If this command fails for some reason, no deployments are displayed.

[cornhoolio22]

Hi harald.pehl,

thx for your repsonse.

Actually, the command you mentioned works (also with recursive=true). The command I wrote above doesn't work.

[standalone@localhost:9990 /] :read-children-resources(child-type=deployment)
{
    "outcome" => "success",
    "result" => {
        "batch-batchlet-simple.war" => {
            "content" => [{
                "hash" => bytes {
                    0xfe, 0x2d, 0xa7, 0x1c, 0x4b, 0x70, 0x30, 0xc6,
                    0x2a, 0x03, 0x66, 0x62, 0x2a, 0x54, 0x42, 0x1d,
                    0x1c, 0xeb, 0x6d, 0x82
                },
                "archive" => undefined
            }],
            "enabled" => true,
            "enabled-time" => 1480580272465L,
            "enabled-timestamp" => "2016-12-01 09:17:52,465 MEZ",
            "name" => "batch-batchlet-simple.war",
            "owner" => undefined,
            "persistent" => true,
            "runtime-name" => "batch-batchlet-simple.war",
            "subdeployment" => undefined,
            "subsystem" => {
                "undertow" => undefined,
                "logging" => undefined,
                "batch-jberet" => undefined
            }
        },
        "batch-chunk-csv-database.war" => {
            "content" => [{
                "hash" => bytes {
                    0x4e, 0x16, 0x6d, 0x65, 0x1b, 0x63, 0x6d, 0x1e,
                    0x75, 0x85, 0xd8, 0x2e, 0x8a, 0xd4, 0x74, 0x63,
                    0x24, 0x5f, 0xb8, 0x66
                },
                "archive" => undefined
            }],
            "enabled" => true,
            "enabled-time" => 1480580272376L,
            "enabled-timestamp" => "2016-12-01 09:17:52,376 MEZ",
            "name" => "batch-chunk-csv-database.war",
            "owner" => undefined,
            "persistent" => true,
            "runtime-name" => "some-other-name.war",
            "subdeployment" => undefined,
            "subsystem" => {
                "jpa" => undefined,
                "undertow" => undefined,
                "logging" => undefined,
                "batch-jberet" => undefined
            }
        }
    }
}

My command is not working:

[standalone@localhost:9990 /] /deployment=batch-chunk-csv-database.war/subsystem=batch-jberet/job=myJob:read-resource(include-runtime=true)  
09:19:05,722 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("deployment" => "batch-chunk-csv-database.war"),
    ("subsystem" => "batch-jberet"),
    ("job" => "myJob")
]): java.lang.NullPointerException
    at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:68)
    at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
    at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
    at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
    at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:988)
    at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
    at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
    at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
    at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
    at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
    at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
    at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
    at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
    at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
    at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
    at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
    at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
    at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
    at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
    at org.jboss.threads.JBossThread.run(JBossThread.java:320)

{
    "outcome" => "failed",
    "rolled-back" => true
}

So some other request prevents the management interface to show the deployments...

Nevertheless, the issue is fixed for me by [WFLY-7570] JBeret WildFly extension cannot handle runtime-name - JBoss Issue Tracker .

Thx for your support.

Cheers,

Markus

[rsmith1]

We are using Wildfly 9.0 and have experienced the same error.

What we have found is:
On deployment, if the name is changed (we usually add version to the name), we get the null pointer exception.

If we leave the name unchanged, it deploys fine.

I dont know if it matters, but our job name matches the war name.