Target alternate WebSphere Installation when run under WebSphere

Hmm - a little unsure if this should be done in the plugin - maybe it can be fixed by running a hudson slave which would provide a neutral environment?

Whilst I understand your concerns. I tend to take a wider view of things. I see the role of the plugin to set up and run tasks in any environment.

Running a Hudson slave (which we can not really do in this case anyway) is a Hudson specific solution. Other CI tools may not be able to manage.

I do realise that I may be one of the few (only?) who need it, but nevertheless I still need it.

However, I just discovered yesterday that I need the same functionality (call a different script) which will allow me to filter the input parameters.

Under WebSphere Process Server (WPS) on AIX, ws_ant (not ws_ant.sh, btw) does not accept the standard -noinput switch. If you pass it, it fails with the error listed below.

The same rev of WPS (6.0.2.4) under Windows accepts the parameter (it either accepts it or is silently ignores it - either way it does not fail).

Here is a section of output:

[INFO] [was6:ejbdeploy

]
[WARNING] Legacy mode - jdkComplianceLevel will NOT be taken into consideration (default will be used)
[INFO] All Parameters [-buildfile /var/WebSphere/Hudson/jobs/eswm-TranServ-S4_ReconReport/workspace/S4_ReconReport_WPSEjb/target/was6-maven-plugin/was6plugin-build.xml -noinput wsEjbDeploy]
[INFO] Unknown argument: -noinput
[INFO] ant [options] [target [target2 [target3] ...]]
[INFO] Options:
[INFO] -help print this message
[INFO] -projecthelp print project help information
[INFO] -version print the version information and exit
[INFO] -diagnostics print information that might be helpful to
[INFO] diagnose or report problems.
[INFO] -quiet, -q be extra quiet
[INFO] -verbose, -v be extra verbose
[INFO] -debug print debugging information
[INFO] -emacs produce logging information without adornments
[INFO] -logfile <file> use given file for log
[INFO] -l <file> ''
[INFO] -logger <classname> the class which is to perform logging
[INFO] -listener <classname> add an instance of class as a project listener
[INFO] -buildfile <file> use given buildfile
[INFO] -file <file> ''
[INFO] -f <file> ''
[INFO] -D<property>=<value> use value for given property
[INFO] -propertyfile <name> load all properties from file with -D
[INFO] properties taking precedence
[INFO] -inputhandler <class> the class which will handle input requests
[INFO] -find <file> search for buildfile towards the root of the
[INFO] filesystem and use it
[INFO]
[INFO] Return code: 0

This error occurs directly from maven - so Hudson is not an issue at all.

So I had to make use of the alternateScript parameter so that I can filter the parameters:

#!/bin/sh

echo "All Parameters Passed In [$@]"

1. Loop until all parameters are used up
   while [ "$1" != "" ]; do

if [ $1 != "-noinput" ]; then
params=$params" "$1
fi

1. Shift all the parameters down by one
   shift

done

echo "Filtered Parameters Passed On [$params]"

unset WAS_USER_SCRIPT

/usr/WebSphere602/ProcServer/bin/ws_ant $params

echo "ws_ant returned $?"

exit $?

Now I get:

[INFO] [was6:ejbdeploy

]
[WARNING] Legacy mode - jdkComplianceLevel will NOT be taken into consideration (default will be used)
[INFO] All Parameters Passed In [-buildfile /var/WebSphere/Hudson/jobs/eswm-TranServ-S4_ReconReport/workspace/S4_ReconReport_WPSEjb/target/was6-maven-plugin/was6plugin-build.xml -noinput wsEjbDeploy]
[INFO] Filtered Parameters Passed On [ -buildfile /var/WebSphere/Hudson/jobs/eswm-TranServ-S4_ReconReport/workspace/S4_ReconReport_WPSEjb/target/was6-maven-plugin/was6plugin-build.xml wsEjbDeploy]
[INFO] Buildfile: /var/WebSphere/Hudson/jobs/eswm-TranServ-S4_ReconReport/workspace/S4_ReconReport_WPSEjb/target/was6-maven-plugin/was6plugin-build.xml
[INFO]
[INFO] wsEjbDeploy:
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Starting workbench.
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] o0829.13
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Creating the project.
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Opening: /S4_ReconReport_WPSEjb.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Setting project description.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Setting output location for: 'S4_ReconReport_WPSEjb'
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Setting classpath for: S4_ReconReport_WPSEjb
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Creating resource /S4_ReconReport_WPSEjb/ejbModule.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..META-INF/ibm-ejb-jar-bnd.xmi
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..com/ibm/issw/reconreport/formatworkbook.dtd
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..com/ibm/issw/reconreport/workbook.dtd
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..com/ibm/issw/reconreport/ReportGenerator.class
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..com/ibm/issw/reconreport/task/ReconReportTaskBean.class
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..META-INF/ejb-jar.xml
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..META-INF/maven/com.ibm.sct.transerv/S4_ReconReport_WPSEjb/pom.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Importing JAR..META-INF/maven/com.ibm.sct.transerv/S4_ReconReport_WPSEjb/pom.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Looking for validation messages owned by uninstalled validators...
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Looking for validation messages owned by uninstalled validators...done.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validating
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Removing Map Validator messages on S4_ReconReport_WPSEjb has started...
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Messages removed.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validation of S4_ReconReport_WPSEjb by Map Validator has started...
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validation of S4_ReconReport_WPSEjb by Map Validator is complete. All known p
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Removing EJB Validator messages on S4_ReconReport_WPSEjb has started...
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Messages removed.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validation of S4_ReconReport_WPSEjb by EJB Validator has started...
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validating com.ibm.issw.reconreport.task.ReconReportTaskBean.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validating com.ibm.websphere.scheduler.TaskHandler.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validating com.ibm.websphere.scheduler.TaskHandlerHome.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validation of S4_ReconReport_WPSEjb by EJB Validator is complete. All known p
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Removing EJB WebSphere Extension Validator messages on S4_ReconReport_WPSEjb
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Messages removed.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validation of S4_ReconReport_WPSEjb by EJB WebSphere Extension Validator has
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Validation of S4_ReconReport_WPSEjb by EJB WebSphere Extension Validator is c
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Generating deployment code
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Processing session bean: ReconReportTask
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Refreshing: /S4_ReconReport_WPSEjb/ejbModule.
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Building: /S4_ReconReport_WPSEjb
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Invoking Java Builder on /S4_ReconReport_WPSEjb.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Preparing for build
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Cleaning output folder
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Analyzing sources
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Compiling S4_ReconReport_WPSEjb/ejbModule/com/ibm/websphere/scheduler
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Build done
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Invoking Validation on /S4_ReconReport_WPSEjb.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Invoking Library Copying Builder on /S4_ReconReport_WPSEjb.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Invoking Structured Document and Model Builder on /S4_ReconReport_WPSEjb.
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Invoking RMIC.
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Generating DDL
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Writing output file
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] Shutting down workbench.
[INFO]
[INFO] [wsejbdeploy]
[INFO] [wsejbdeploy] EJBDeploy complete.
[INFO] [wsejbdeploy] 0 Errors, 0 Warnings, 0 Informational Messages
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO] Total time: 32 seconds
[INFO] ws_ant returned 0
[INFO] Return code: 0
[INFO] ejbDeploy finished

Because this error occurs under pure Maven and only on AIX with WPS, I would like this patch (and I've already got a documentation update for it) committed so that I can kill two birds with one stone.

It enables me to run ejbDeploy with WPS 6.0.2.4, AND run everything under Hudson as well whilst targeting an alternate WebSphere base version.

Thanks.

-Chris

#!/bin/sh

echo "All Parameters Passed In         [$@]"

# Loop until all parameters are used up
while [ "$1" != "" ]; do

    if [ $1 != "-noinput" ]; then
        params=$params" "$1
    fi

    # Shift all the parameters down by one
    shift

done

echo "Filtered Parameters Passed On    [$params]"

unset WAS_USER_SCRIPT

/usr/WebSphere602/ProcServer/bin/ws_ant $params

wsAntReturnCode=$?

echo "ws_ant returned [$wsAntReturnCode]"

exit $wsAntReturnCode

That is the correct working unix script.

-Chris

Hi - can you try this patch? It should remove the WAS_USER_SCRIPT variable before executing the shell.

Sure, I can try it.

However, it will not address the -noinput problem from Process Server on AIX.

That was the other use I put the alternate script function to.

It nicely killed two birds with the one stone.

-Chris

It might be more feasible just to add "websphereVersion" parameter, instead of complicating things with alternate scripts.
Depending on this parameter the plugin could decide whether to add "-nonput" argument or not. It also might be useful if any other differencies would be found.

Btw, having the same version of WS on every environment including development, CI and production is the most common practice (and the best one).

It might be more feasible just to add "websphereVersion" parameter, instead of complicating things with alternate scripts. Depending on this parameter the plugin could decide whether to add "-nonput" argument or not. It also might be useful if any other differencies would be found.

It is not a version difference, it is a platform difference. The same revision of Process Server (in this case 6.0.2.4) on windows does not have the parameter, but it does not fail it it is supplied. The same version on AIX, however, terminates with an error message.

Btw, having the same version of WS on every environment including development, CI and production is the most common practice (and the best one).

I am well aware of that, and we do have the same versions across all 10 environments (except when we are rolling out patches - cann't do them all at once).

This issue has not come about because we have different versions on the one box. It has come about because we have multiple versions on the one box.

Well, LPAR actually. This LPAR, has:

WPS 6.0.2.4, which includes ??? of ESB and an underlying version 6.0.2.31 of WAS.
WAS 6.1.0.15, and
Portal ????

In this case, Hudson requires Java 1.5 to run, so it is installed in a Cluster under WAS 6.1. But when I am generating Process Server and normal J2EE ears for WPS, it needs to target the 6.0.2.4 WPS code - especially for deployments.

-Chris

It is not a version difference, it is a platform difference. The same revision of Process Server (in this case 6.0.2.4) on windows does not have the parameter, but it does not fail it it is supplied. The same version on AIX, however, terminates with an error message.

This issue has not come about because we have different versions on the one box. It has come about because we have multiple versions on the one box.

This issue has not come about because we have different versions on the one box. It has come about because we have multiple versions on the one box.

In this case the best solution would be to use multiple maven profiles.

On the contary, just how do you think that profiles would address this issue?

The issue here is that because we're running from a WAS 6.1 process, it has all of the WAS 6.1 environment variables set. One if them is the WAS_USER_SCRIPT, which is designed to allow custom setup for specific profiles.

The issue here is that if this particular variable is set, when setupCmdLine.sh|bat is called (which is called by basically all shell or batch files, and ws_ant is one of them) then NO initialization takes place.

The issue then is that you are trying to setup and use a different WPS (or base WAS for that matter) version than what has already been initialised.

The only means to reinitialize the environment is to remove the WAS_USER_SCRIPT variable.

So, as all of this happens when the was6-maven-plugin calls ws_ant or ws_ant.sh or ws_ant.bat, we have left maven's control and passed it to the shell/batch script.

How would use of profiles fix this?

-Chris

The noinput had already been commited long time ago:
http://fisheye.codehaus.org/browse/mojo/trunk/mojo/was6-maven-plugin/src/main/java/org/codehaus/mojo/was6/AbstractWas6Mojo.java?r1=8384&r2=8407

I really think Roman's suggestion about having a base was-version flag is the most elegant solution - and use the unset environment hack for environements running under was.

That's also why this should be two different issues so they can be tracked on different issues (and solutions).

I had considered that solution myself. I realised that it had to apply to all mojos. I wasn't sure if you'd have wanted such a global impact to the code.

Yes, I agree, it is the most elegant for the env variable problem.

The -noinput hack I put together was originally for the servicedeploy mojo.

But when I started using it with the ejbdeploy mojo, I ran across the same issue. ws_ant on AIX has a lot of issues... That is when I found out that the -noinput issue was not just specific to servicedeploy - ws_ant under Process Server on AIX - it was for all functions. And that is a little more pervasive.

So, I simply leveraged the solution that I had available to me.

-Chris

Did the unset variable hack work?

The problem with environment variables could be solved by invoking ws_ant from plugin in this way:

env --ignore-environment /path/to/websphere/bin/ws_ant ...

or

/bin/sh -c "unset WAS_USER_SCRIPT; /path/to/websphere/bin/ws_ant ..."

again without complicating it with scripts

A variation of David's patch has been applied and is available downloading and compiling the trunk. Anybody with the same problem could test it?

Preparing 1.2 version release