3 Replies Latest reply on Mar 9, 2018 4:05 AM by James Alfei

    Unable to deploy via Maven to EAP 7.0 through Wildfly deploy plugin

    James Alfei Newbie

      So i've followed the instructions on the WildFly maven deploy plugin page (WildFly Maven Plugin – Usage ) but have noticed an issue.

       

      When i am running my local JBoss EAP 7.0 using the access control provider of "simple", everything works fine as expected. The moment i change this to "rbac" provider i cannot get the app to deploy at all.

       

      I have created a specific user for the maven deployment plugin and tried both "super user" and "deployer" roles but to no avail. I've tried supplying no username and password, using an existing superuser etc but again to no avail.

       

      I get an error when i try to deploy of the following:

      [INFO] --- wildfly-maven-plugin:1.2.1.Final:deploy (default-cli) @ AppName ---
      Mar 05, 2018 10:56:15 AM org.jboss.remoting3.EndpointImpl 
      INFO: JBoss Remoting version 5.0.0.Final
      Mar 05, 2018 10:56:15 AM org.xnio.Xnio 
      INFO: XNIO version 3.5.1.Final
      Mar 05, 2018 10:56:15 AM org.xnio.nio.NioXnio 
      INFO: XNIO NIO Implementation Version 3.5.1.Final
      Mar 05, 2018 10:56:15 AM org.wildfly.security.Version 
      INFO: ELY00001: WildFly Elytron version 1.1.0.Final
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD FAILURE
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 9.046 s
      [INFO] Finished at: 2018-03-05T10:56:16+00:00
      [INFO] Final Memory: 38M/536M
      [INFO] ------------------------------------------------------------------------
      [ERROR] Failed to execute goal org.wildfly.plugins:wildfly-maven-plugin:1.2.1.Final:deploy (default-cli) on project AppName: Execution default-cli of goal org.wildfly.plugins:wildfly-maven-plugin:1.2.1.Final:deploy failed: WFLYCTL0216: Management resource '[]' not found -> [Help 1]

       

      I'm using the following in my pom.xml:

       

      <plugin>
           <groupId>org.wildfly.plugins</groupId>
           <artifactId>wildfly-maven-plugin</artifactId>
           <version>1.2.1.Final</version>
           <configuration>
                <username>mavenDeploy</username>
                <password>deploy</password>
           </configuration>
      </plugin>
      

       

      and our standalone.xml has the access control set up as follows:

       

           <access-control provider="rbac">
                  <role-mapping>
                      <role name="SuperUser">
                          <include>
                              <user name="admin"/>
                              <user name="userOne"/>
                              <user name="mavenDeploy"/>
                          </include>
                      </role>
                      <role name="Deployer">
                          <include>
                              <user name="mavenDeploy"/>
                          </include>
                      </role>
                  </role-mapping>
              </access-control>
      

       

      Note the mavenDeploy user set up in both for testing.

       

      Am i missing a user? Am i supposed to use a specific role for the plugin?

       

      Would appreciate any support regarding this!

       

      Thanks

        • 1. Re: Unable to deploy via Maven to EAP 7.0 through Wildfly deploy plugin
          James Perkins Master

          It looks like the callback handler isn't being invoked for some reason. I'll have to look into why this might be happening.

           

          --

          James R. Perkins

          • 2. Re: Unable to deploy via Maven to EAP 7.0 through Wildfly deploy plugin
            James Perkins Master

            You probably still partially have local authentication enabled. Once I removed that it seemed to work. I used the following CLI command to remove local authentication.

             

            /core-service=management/security-realm=ManagementRealm/authentication=local:remove

             

            Once that was removed with CLI I was prompted for a username and password. The wildfly-maven-plugin was also able to deploy.

             

            Given you're configuration below you may need to add the the $local user back to your role mapping though.

            <access-control provider="rbac">  
                <role-mapping>  
                    <role name="SuperUser">  
                        <include>
                            <user name="$local"/>
                            <user name="admin"/>  
                            <user name="userOne"/>  
                            <user name="mavenDeploy"/>  
                        </include>  
                    </role>  
                    <role name="Deployer">  
                        <include>  
                            <user name="mavenDeploy"/>  
                        </include>  
                    </role>  
                </role-mapping>  
            </access-control>  
            

             

            --

            James R. Perkins

            • 3. Re: Unable to deploy via Maven to EAP 7.0 through Wildfly deploy plugin
              James Alfei Newbie

              Hi James.

               

              Thanks for this, it worked like a charm!

               

              After looking at the standalone.xml before and after running that command, the only actual difference is that the following was removed from the standalone.xml:

               

               

              <management>
                      <security-realms>
                          <security-realm name="ManagementRealm">
                              <authentication>
                                  <local default-user="$local" skip-group-loading="true"/> <!-- THIS LINE WAS REMOVED -->
              

               

              After reverting the changes back to local, then rbac and removing this line everything worked as expected. This was able to be done without adding the "$local" user to access control.

               

              Thanks for looking into this for us!