Mojo's WebSphere 6 Maven Plugin
  1. Mojo's WebSphere 6 Maven Plugin
  2. MWAS-52

WsAdminMojo does not work on a secured connection.

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2
    • Labels:
      None
    • Environment:
      WAS 7.0 standalone server / Windows 32 bits.
    • Number of attachments :
      3

      Description

      I ran the attached pom succesfully on an unsecured WAS 7.0 server.

      The POM runs a jython script, uninstalls an EAR, installs it again and runs the jython script again. This works on WAS 7.0.

      Once I secure the server the WsAdminMojo fails. The WsUninstallAppMojo and WsInstallAppMojo work.

      The jython script is not special at this moment yet: it prints "hello world" to the console.

      I have attached the following files:

      • secured_run.txt - a run on a secured connection;
      • unsecured_run.txt - a run on a unsecured connection;
      • pom.xml - my pom;

      IŽd like to run the jython script on a secured server to modify application scoped resources. This will allow us to run a nightly build, deploy, configire and jmeter test from maven.

      I ran the pom in debug mode and I discovered that the user is null when it hits the WsAdminMojo. The other variables like password, host and so on are set.

      I will see what I can do to set the user in the WsAdminMojo.

      1. pom.xml
        6 kB
        Ronald van de Kuil
      2. secured_run.txt
        30 kB
        Ronald van de Kuil
      3. unsecured_run.txt
        39 kB
        Ronald van de Kuil

        Activity

        Hide
        Ronald van de Kuil added a comment -

        to be exact, as soon as the debugger enters WsAdminMojo.configureBuildScript I can see that the password, host, port are set but the user is not set. It is null.

        Show
        Ronald van de Kuil added a comment - to be exact, as soon as the debugger enters WsAdminMojo.configureBuildScript I can see that the password, host, port are set but the user is not set. It is null.
        Hide
        Ronald van de Kuil added a comment - - edited

        Found it: this mojo uses the user element instead of username element.

        My workaround is to include the following 2 elements in the configuration of the plugin:

        <user>wasadmin</user>
        <username>wasadmin</username>

        The workaround supplies user for the WsAdminMojo and username for the WsInstallMojo and WsUninstallMojo

        The permanent fix is to change WsAdminMojo to use username instead of user.

        I currently do not know how to make this change.

        Show
        Ronald van de Kuil added a comment - - edited Found it: this mojo uses the user element instead of username element. My workaround is to include the following 2 elements in the configuration of the plugin: <user>wasadmin</user> <username>wasadmin</username> The workaround supplies user for the WsAdminMojo and username for the WsInstallMojo and WsUninstallMojo The permanent fix is to change WsAdminMojo to use username instead of user. I currently do not know how to make this change.
        Hide
        David J. M. Karlsen added a comment -

        Good catch - I didn't notice the differences when implementing this as the mojos pretty much reflect the ant tasks - and they have inconsistent attribute naming: http://publib.boulder.ibm.com/infocenter/wasinfo/v5r0/index.jsp?topic=/com.ibm.wasee.doc/info/ee/javadoc/ae/com/ibm/websphere/ant/tasks/package-tree.html
        Should be able to abstract this in the mojos and map them to either user or username depending on the task at hand.
        I'll try to fix this in the next release by consistently naming the element "username" in the mojo (and probably support the old element as well, but deprecate it.

        Show
        David J. M. Karlsen added a comment - Good catch - I didn't notice the differences when implementing this as the mojos pretty much reflect the ant tasks - and they have inconsistent attribute naming: http://publib.boulder.ibm.com/infocenter/wasinfo/v5r0/index.jsp?topic=/com.ibm.wasee.doc/info/ee/javadoc/ae/com/ibm/websphere/ant/tasks/package-tree.html Should be able to abstract this in the mojos and map them to either user or username depending on the task at hand. I'll try to fix this in the next release by consistently naming the element "username" in the mojo (and probably support the old element as well, but deprecate it.
        Hide
        Javier Murciego added a comment -

        The issue has been resolved and is available at 1.2-SNAPSHOT. The final property name is user in all the goals

        Show
        Javier Murciego added a comment - The issue has been resolved and is available at 1.2-SNAPSHOT. The final property name is user in all the goals
        Hide
        Javier Murciego added a comment -

        Preparing 1.2 version release

        Show
        Javier Murciego added a comment - Preparing 1.2 version release

          People

          • Assignee:
            Javier Murciego
            Reporter:
            Ronald van de Kuil
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: