7 Replies Latest reply on Apr 20, 2017 12:55 PM by Robert Smith

    JBeret WildFly extension cannot handle runtime-name

    Markus Falk Newbie

      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

        • 1. Re: JBeret WildFly extension cannot handle runtime-name
          jaikiran pai Master

          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?

          • 2. Re: JBeret WildFly extension cannot handle runtime-name
            Markus Falk Newbie

            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

            • 3. Re: JBeret WildFly extension cannot handle runtime-name
              jaikiran pai Master

              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.

              • 4. Re: JBeret WildFly extension cannot handle runtime-name
                Markus Falk Newbie

                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.

                • 5. Re: JBeret WildFly extension cannot handle runtime-name
                  Harald Pehl Newbie

                  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.

                  • 6. Re: JBeret WildFly extension cannot handle runtime-name
                    Markus Falk Newbie

                    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

                    • 7. Re: JBeret WildFly extension cannot handle runtime-name
                      Robert Smith Newbie

                      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.