Giter VIP home page Giter VIP logo

liberty-arquillian's Introduction

Arquillian Liberty Server Containers Maven Central Latest Build Status Maven Central 1.x Build Status 1.x

Arquillian is a testing framework to develop automated functional, integration and acceptance tests for your Java applications. Arquillian container adapters allow Arquillian to bind to and manage the lifecycle of a runtime. There are two types of Arquillian container adapters for Liberty: Liberty Managed and Liberty Remote.

Arquillian Liberty Managed Container

An Arquillian container adapter (DeployableContainer implementation) that can start and stop a local Liberty process and run tests on it over a remote protocol (effectively in a different JVM). For an introduction to testing microservices with the Arquillian Liberty Managed container and Open Liberty, check out the this guide.

Jakarta EE 9 and 10: for Arquillian Liberty Managed container documentation with Jakarta EE 9 and EE 10, click here.

Java EE 8 or below: for Arquillian Liberty Managed container documentation with Java EE 8 or below, click here.

Arquillian Liberty Remote Container

An Arquillian container adapter (DeployableContainer implementation) that can connect and run against a remote (different JVM, different machine) Liberty server and run tests on it over a remote protocol (effectively in a different JVM).

Jakarta EE 9 and 10: for Arquillian Liberty Remote container documentation with Jakarta EE 9 and EE 10, click here.

Java EE 8 or below: for Arquillian Liberty Remote container documentation with Java EE 8 or below, click here.

Testing

To run tests, you will need to specify the following parameters:

Parameter Description
runtime The runtime to use. Specify ol for Open Liberty, olbeta for Open Liberty beta, and wlp-ee9 or wlp-ee10 for WebSphere Liberty.
runtimeVersion Version of the specified runtime to use.

For example, to run tests on version 22.0.0.6 of the Open Liberty runtime, use the following command:

mvn verify -Druntime=ol -DruntimeVersion=22.0.0.6

EE 9 archive images are no longer published for WebSphere Liberty so runtimeVersion is ignored for wlp-ee9 and 23.0.0.2 is used which is the last version of the wlp-jakartaee9 archive that was published.

liberty-arquillian's People

Contributors

aguibert avatar andymc12 avatar arjantijms avatar aslakknutsen avatar azquelt avatar bartoszmajsak avatar benjamin-confino avatar brideck avatar cherylking avatar chri-arz avatar chyt avatar dependabot[bot] avatar dshimo avatar gpoul avatar hibell avatar hutchig avatar jhanders34 avatar kathrynkodama avatar lebetz avatar marianmacik avatar mynameisboris avatar nottycode avatar nstewart0206 avatar rzgry avatar tjayr avatar wasdevb1 avatar winklerm avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

liberty-arquillian's Issues

Container waits for entire timeout if application failed to deploy

Issue Overview

Currently, running the CDI TCK against Liberty takes about 3 hours and 20 minutes to complete. It looks like the container waits for the application MBean to reach the STARTED state and only gives up after the timeout elapses.

The CDI TCK uses many broken applications to test that they do not deploy, so waiting the entire timeout for each test is not ideal. However, with the changes in this pull request, the CDI TCK now runs in approximately 50 minutes now.

Expected Behaviour

Do not wait for timeout for application that failed to deploy.

Current Behaviour

Container waits for a timeout to elapse before checking the logs to see if the application failed due to a deployment exception causing tests to take much longer to finish.

Steps To Reproduce
  1. Deploy a CDI application that fails to start up due to a CDI deployment exception.

server.env file not being resolved

Issue Overview

When running an arquillian liberty managed container test, the specifiec environment variables are not resolved in the server.xml file. WLPManagedContainer.class can be seen trying to find the server.env, however, a running app in the runtime using server.env is not resolved during testing.

Expected Behaviour

A server.xml file containing e.g. <jndiEntry jndiName="env/foo" value="${env.foo}"/> and foo=bar defined in server.env in the running server directory. Should be resolved during the in-container test.
When fetching the jndiEntry using @Resource(lookup="env/foo") String foo; should resolve to bar in runtime as well as during arquillian testing
See: https://github.com/HasseNasse/liberty-arquillian-envvars

Current Behaviour

Application servlet resolves @Resource(lookup="env/foo") String foo; to bar during application deployment. Whilst during Arquillian testing the @Resource(lookup="env/foo") String foo; resolves to ${env.foo}, as defined in server.xml.

Tested using both Java 11 (Azul Zulu) and Java 8 (Azul Zulu + Oracle JDK)

Steps To Reproduce

Running Arquillian test:

  1. git clone https://github.com/HasseNasse/liberty-arquillian-envvars.git
  2. mvn verify

Deploying Application

  1. git clone https://github.com/HasseNasse/liberty-arquillian-envvars.git
  2. mvn liberty:start-server
  3. cp target/<artifact> target/liberty/wlp/user/servers/defaultserver/dropins
  4. Navigate to http://localhost:9080/net_nazarsit_arq_war/foo

Connect timeout error when ran tests against liberty-managed

The sample project is here.

Openliberty 20.0.0.1
AdaptOpenJDK 8

The configuaration for arquillian liberty-managed profile.

 <profile>
            <!-- Run with: mvn clean test -Parq-liberty-managed -->
            <id>arq-liberty-managed</id>
            <properties>
                <skipTests>false</skipTests>
            </properties>
            <dependencies>
                <dependency>
                    <groupId>io.openliberty.arquillian</groupId>
                    <artifactId>arquillian-liberty-managed</artifactId>
                    <version>${arquillian-liberty.version}</version>
                </dependency>
            </dependencies>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-dependency-plugin</artifactId>
                        <version>${maven-dependency-plugin.version}</version>
                        <executions>
                            <execution>
                                <id>unpack</id>
                                <phase>pre-integration-test</phase>
                                <goals>
                                    <goal>unpack</goal>
                                </goals>
                                <configuration>
                                    <artifactItems>
                                        <artifactItem>
                                            <groupId>io.openliberty</groupId>
                                            <artifactId>openliberty-runtime</artifactId>
                                            <version>${liberty.runtime.version}</version>
                                            <type>zip</type>
                                            <overWrite>false</overWrite>
                                            <outputDirectory>${project.build.directory}</outputDirectory>
                                        </artifactItem>
                                    </artifactItems>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <artifactId>maven-failsafe-plugin</artifactId>
                        <version>${maven-failsafe-plugin.version}</version>
                        <configuration>
                            <!--<environmentVariables>
                                <WLP_HOME>${project.build.directory}/wlp</WLP_HOME>
                            </environmentVariables>-->
                            <systemProperties>
                                <arquillian.launch>liberty-managed</arquillian.launch>
                            </systemProperties>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

And the arquillian.xml file content:

    <container qualifier="liberty-managed">
        <configuration>
            <property name="wlpHome">target/wlp/</property>
            <property name="serverName">defaultServer</property>
            <property name="httpPort">9080</property>
            <property name="serverStartTimeout">300</property>
        </configuration>
    </container>

When running the test via the following command:

mvn clean verify -Parq-liberty-managed

And got the info from the console. The Github Actions build log can be found here.

087 seconds.
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 311.064 s <<< FAILURE! - in com.example.it.GreetingResourceTest
[ERROR] com.example.it.GreetingResourceTest  Time elapsed: 311.05 s  <<< ERROR!
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Unable to retrieve connector address for localConnector of started VM

[INFO] Running com.example.it.GreetingServiceTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.03 s <<< FAILURE! - in com.example.it.GreetingServiceTest
[ERROR] com.example.it.GreetingServiceTest  Time elapsed: 0.018 s  <<< ERROR!
java.lang.RuntimeException: Arquillian initialization has already been attempted, but failed. See previous exceptions for cause
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Unable to retrieve connector address for localConnector of started VM

[AUDIT   ] CWWKE0055I: Server shutdown requested on Friday, February 7, 2020 at 4:44 PM. The server defaultServer is shutting down.
[AUDIT   ] CWWKE1100I: Waiting for up to 30 seconds for the server to quiesce.
[INFO    ] CWWKE1101I: Server quiesce complete.
[AUDIT   ] CWWKE0036I: The server defaultServer stopped after 5 minutes, 12.017 seconds.
Picked up JAVA_TOOL_OPTIONS: -Dcom.ibm.ws.logging.console.log.level=INFO
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0

Invoking liberty-arquillian plugin via maven uses shell 'WLP_USER_DIR' env var, which may not be set correctly.

Issue Overview

Invoking liberty-arquillian plugin via mvn with the WLP_USER_DIR set can cause a failure to start the Liberty server, if it is not set to wlpHome/usr.

Possible Symptoms:

Taking mainly the defaults of liberty-maven-plugin, e.g. as with the guide app: https://openliberty.io/guides/arquillian-managed.html#running-the-tests, I get something like this:

Launching defaultServer (Open Liberty 21.0.0.5/wlp-1.0.52.cl210520210510-1231) on Eclipse OpenJ9 VM, version 11.0.11+9 (en_US)
[AUDIT ] CWWKE0001I: The server defaultServer has been launched.
[INFO ] CWWKE0002I: The kernel started after 5.133 seconds
[INFO ] CWWKF0007I: Feature update started.
[ERROR ] CWWKF0001E: A feature definition could not be found for jsp-2.3
[INFO ] CWWKF0008I: Feature update completed in 0.364 seconds.
[AUDIT ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 5.507 seconds.

Steps To Reproduce
  1. From your shell:

export WLP_USER_DIR=.../some/other/wlp/usr

  1. Clone the ci.maven project (will take a few minutes to get this far)

[email protected]:WASdev/ci.maven.git

  1. Run integration tests

mvn install -Ponline-its -Druntime=ol -DruntimeVersion=18.0.0.2

  1. Look for the failure in: .../target/it/arquillian-tests/build.log

Workaround

You can workaround by:

unset WLP_USER_DIR

Suggested solution

Back here deploy was changed to only look at WLP_USER_DIR in one of the server.env locations.

Perhaps, to be consistent we should do something similar.

There are a few variations on this I could think up quick:

  • perhaps WLPManagedContainer.start() should unset this WLP_USER_DIR env var before launching the server
  • perhaps server.env should itself contain the location when it is generated

to only look at one of the server.env files.

Make wlpHome unnecessary

Enhancement
https://stackoverflow.com/questions/54390667/arquillian-and-open-liberty-requires-existing-installation/54424464#54424464

Issue Overview

I'm familiar with Tomcat/TomEE and testing applications using Arquillian. Now were are switching to Open Liberty. I see there is a module for Arquillian using embedded Open Liberty but it seems to require an existing Open Liberty installation whose path is provided in the configuration. This makes it non-portable and therefore unsuitable for automated testing since the installation has to be present at the exact same path. Arquillian and TomEE are self-contained, no installation required. Therefore my question is why this isn't also possible with Open Liberty? And is this planned for the future?

For reference this is how you use Arquillian with TomEE/Tomcat:

<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://jboss.org/schema/arquillian"
    xsi:schemaLocation="http://jboss.org/schema/arquillian http://www.jboss.org/schema/arquillian/arquillian_1_0.xsd">
    <container qualifier="tomee" default="true">
        <configuration>
            <property name="httpPort">-1</property>
            <property name="stopPort">-1</property>
            <property name="users">user=pass</property>
        </configuration>
    </container>
</arquillian>

As you can see, there is no path to a local installation required to run the tests. The only thing you need to do is a add a couple of Maven dependencies in test scope that pull in TomEE (embedded). If the same would work for Open Liberty that would be great.

J2EEManagement JMX request for EAR files does not work on WLP 18.0.0.2 javaee-7

Issue Overview

On Websphere Liberty Profile 18.0.0.2 (with enabled javaee-7 and J2EE management), the JMX query to
retrieve the servlet names return an empty result list, caused by the used JMX object String in WLPManagedContainer:

  • The one implemented, returns empty list: WebSphere:*,J2EEApplication=eararchive,j2eeType=Servlet,WebModule=/webmodule

  • This one works: WebSphere:*,J2EEServer=defaultServer,J2EEApplication=eararchive,j2eeType=Servlet,WebModule=webmodule

(In case there is a defaultServer with a deployed eararchive.ear that contains a webmodule.war)

Problem is that for EAR deployments with multiple WAR submodules, @ArquillianResource URL injection always returns context root of the hard-coded testable WAR module that contains the Arquillian servlet, which is wrong in most cases.

Expected Behaviour

Servlets should be retrieved and reported to Arquillian as protocol metadata successfully when J2EEManagement is enabled for WLP

Current Behaviour

Only the ArquillianServlet with testable web archive's context root is reported to arquillian as protocol metadata.

Steps To Reproduce
  1. Deploy EAR application with multiple WAR webapps (with Servlets) inside.
  2. Debug into WLPManagedContainer to see that only the hard-coded ArquillianServlet is reported
  3. Let Arquillian inject URL for specific Servlet that is located in another webapp than the ArquillianServlet
  4. Injected URL contains context-root of the ArquillianServlet webapp
Additional Information

I prepared a pull request for this issue. Could you please help by checking if that PR can be merged into your codebase? If there are any wishes to improve my PR, feel free to contact me.

Thank you very much,
Christian

Fix the 1.x-maintenance branch so it builds

Issue Overview

The 1.x-maintenance branch was created to provide fixes to the 1.x version stream which is compatible with Java EE 8 projects. The Travis build is currently failing and there are no github actions for builds.

Expected Behaviour

The Travis builds should pass and there should be github actions for builds.

Current Behaviour

The Travis build is currently failing and there are no github actions for builds.

Steps To Reproduce
  1. Submit any PR on the 1.x-maintenance branch and the Travis build will fail.
Additional Information

None

Plugin not usable for JDK 9+

Issue Overview

As of Java 9 the tools jar at JAVA_HOME/tools.jar has been removed and converted to a module. When running a project on JDK 9+ that includes the liberty-arquillian plugin, we get an error like this:

[ERROR] Failed to execute goal on project tck.runner.tck: Could not resolve dependencies for project com.ibm.ws.microprofile.config:tck.runner.tck:jar:1.0-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.6.0 at specified path /home/java/openJ9_jdk10_20180611-sdk/../lib/tools.jar -> [Help 1]

Steps To Reproduce
  1. Can run mvn verify -Druntime=ol -DruntimeVersion=18.0.0.1 on this repo with JDK 9+

Liberty reports various read errors when deploymentType=dropins is used

Issue Overview

Occasionally, when using deploymentType=dropins, Liberty will fail to start the application, usually citing some kind of zip file read error trying to read the application archive.

Expected Behaviour

The application should start

Current Behaviour

The application does not start

Steps To Reproduce
  1. Use deploymentType=dropins
  2. Put tests into your product CI and wait for one of the tests to fail randomly in a build eventually.
Additional Information

I suspect this is caused by liberty reading the application archive before shrinkwrap has finished writing it. I would suggest writing the application to a temp location first and then moving it into the dropins directory afterwards.

Alternatively, liberty could be changed to cope with seeing an incomplete archive in the dropins directory.

Update: although I still think the incomplete application archive could be a problem and I will still submit a pull request for it, in my case I believe the cause was that apps in dropins can be in INSTALLED state before liberty starts them but the container assumes that an app in INSTALLED state has failed to start.

Update: confirmed that both cases described above can occur and have similar symptoms. Both fixed by #21

Deployment exceptions sometimes not reported correctly

Issue Overview

When writing tests with deployments annotated with @ShouldThrowException, the test sometimes fails even when the correct exception is thrown because the full exception cause chain is not propagated back by the container.

This happens even after the resolution of #6 because liberty limits the number of FFDC logs produced by a single point to ten per day. App failures are usually logged with the same outer exception at the same point, so only the first ten failures are reported correctly.

Expected Behaviour

Deployment exception reported correctly

Current Behaviour

Only the first 10 deployment exceptions are reported correctly

Steps To Reproduce
  1. Run a test bucket which requires more than 10 app deployment failures (e.g. the current MP fault tolerance TCK)
Additional Information

This could be resolved by installing a user feature into the runtime which could use existing SPIs to retrieve the startup exception and report that information back to the client.

usr:arquillian-support-1.0 is not found

When I have add usr:arquillian-support-1.0 feature to server.xml and start the application server and got the error info like this.

[ERROR   ] CWWKF0001E: A feature definition could not be found for usr:arquillian-support-1.0

Read server.xm, server.env from test classpath

Currently, it only read the files from server config folders, which add some tedious work for developers, and there is no doc to explain this. Please pick up the files from test classpath firstly or somewhere in the test classpath. Thus there is no extra need to configure it.

What developers need is Convention over configuration.

Detect names of servlets from web.xml

With the j2eemangement feature no longer being supported for Jakarta EE 9, we need a new way to detect the names of servlets when multiple applications are deployed and we must inject multiple servlets.

See these tests for example uses: https://github.com/OpenLiberty/liberty-arquillian/tree/master/liberty-managed/src/test/java/io/openliberty/arquillian/managed/needsmanagementmbeans

We should get the web.xml file from the WebArchive and use that to determine the servlet names.

Unable to stop server after upgrade to 1.0.7 (using `usrDir` property in arquillian.xml)

After upgrading to liberty-arquillian-managed to 1.0.7, I've configured pom.xml to use the new usrDir property:

  <build>
      <plugin>
        <groupId>io.openliberty.tools</groupId>
        <artifactId>liberty-maven-plugin</artifactId>
        <version>3.3.4</version>
        <configuration>
          <serverName>my-project</serverName>
          <configFile>src/main/liberty/server.xml</configFile>
          <configDirectory>src/main/liberty/local</configDirectory>
          <userDirectory>C:/wlp-usr</userDirectory>
          <arquillianProperties>
            <usrDir>C:/wlp-usr</usrDir>
          </arquillianProperties>
        </configuration>
      </plugin>
  </build>

After this change, liberty-arquillian-managed became unable to stop the server. A java process is left dangling (with open ports and files locked).

Full output for ฮป mvn test-compile liberty:create liberty:install-feature liberty:configure-arquillian failsafe:integration-test failsafe:verify

[INFO] Scanning for projects...
[INFO]
[INFO] ---------< my-project:my-project >----------
[INFO] Building my-project 1.0.4-SNAPSHOT
[INFO] --------------------------------[ war ]---------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ my-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\my-project\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ my-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 10 source files to C:\my-project\target\classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ my-project ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ my-project ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:\my-project\target\test-classes
[INFO]
[INFO] --- liberty-maven-plugin:3.2.2:create (default-cli) @ my-project ---
[INFO] CWWKM2102I: Using artifact based assembly archive : io.openliberty:openliberty-kernel:null:21.0.0.4:zip.
[INFO] CWWKM2102I: Using installDirectory : C:\my-project\target\liberty\wlp.
[INFO] CWWKM2102I: Using serverName : my-project.
[INFO] CWWKM2102I: Using serverDirectory : C:\wlp-usr\servers\my-project.
[INFO] CWWKM2185I: The liberty-maven-plugin configuration parameter "appsDirectory" value defaults to "apps".
[INFO] Installing assembly...
[INFO] Expanding: C:\Users\rslemos\.m2\repository\io\openliberty\openliberty-kernel\21.0.0.4\openliberty-kernel-21.0.0.4.zip into C:\my-project\target\liberty
[INFO] CWWKM2143I: Server my-project does not exist. Now creating...
[INFO] CWWKM2001I: Invoke command is ["C:\my-project\target\liberty\wlp\bin\server.bat", create, my-project].
[INFO] Servidor my-project criado.
[INFO] CWWKM2129I: Server my-project has been created at C:\wlp-usr\servers\my-project.
[INFO] Copying 4 files to C:\wlp-usr\servers\my-project
[INFO] Copying 1 file to C:\wlp-usr\servers\my-project
[INFO] CWWKM2144I: Update server configuration file server.xml from C:\my-project\src\main\liberty\server.xml.
[INFO] CWWKM2144I: Update server configuration file jvm.options from inlined configuration.
[INFO] CWWKM2144I: Update server configuration file bootstrap.properties from C:\my-project\src\main\liberty\local\bootstrap.properties.
[INFO]
[INFO] --- liberty-maven-plugin:3.2.2:install-feature (default-cli) @ my-project ---
[INFO] CWWKM2102I: Using artifact based assembly archive : io.openliberty:openliberty-kernel:null:21.0.0.4:zip.
[INFO] CWWKM2102I: Using installDirectory : C:\my-project\target\liberty\wlp.
[INFO] CWWKM2102I: Using serverName : my-project.
[INFO] CWWKM2102I: Using serverDirectory : C:\wlp-usr\servers\my-project.
[INFO] Installing features: [jndi-1.0, cdi-2.0, jdbc-4.2, localconnector-1.0, beanvalidation-2.0, mphealth-3.0, jaxrs-2.1]
[INFO] Product validation completed successfully.
[INFO] The following features have been installed: jndi-1.0 cdi-2.0 jdbc-4.2 localConnector-1.0 el-3.0 beanValidation-2.0 servlet-4.0 mpConfig-2.0 json-1.0 mpHealth-3.0 jsonp-1.1 jaxrsClient-2.1 jaxrs-2.1 servlet-3.1
[INFO]
[INFO] --- liberty-maven-plugin:3.2.2:configure-arquillian (default-cli) @ my-project ---
[INFO] CWWKM2102I: Using artifact based assembly archive : io.openliberty:openliberty-kernel:null:21.0.0.4:zip.
[INFO] CWWKM2102I: Using installDirectory : C:\my-project\target\liberty\wlp.
[INFO] CWWKM2102I: Using serverName : my-project.
[INFO] CWWKM2102I: Using serverDirectory : C:\wlp-usr\servers\my-project.
[INFO] Automatically detected the Arquillian Liberty Managed container at the following coordinates: io.openliberty.arquillian:arquillian-liberty-managed.
[INFO]
[INFO] --- maven-failsafe-plugin:3.0.0-M5:integration-test (default-cli) @ my-project ---
[INFO]
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running br.myPackage.resource.MyResourceIT
Launching my-project (Open Liberty 21.0.0.4/wlp-1.0.51.cl210420210407-0944) on IBM J9 VM, version 8.0.6.10 - pwa6480sr6fp10-20200408_01(SR6 FP10) (en_BR)
[AUDIT   ] CWWKE0001I: The server my-project has been launched.
[AUDIT   ] CWWKG0028A: Processing included configuration resource: C:\wlp-usr\shared\config\jdbc\ojdbc7-12.1.0.2.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: C:\wlp-usr\servers\my-project\configDropins\overrides\arquillian-server.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: C:\wlp-usr\servers\my-project\configDropins\overrides\liberty-plugin-variable-config.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: C:\wlp-usr\servers\my-project\configDropins\overrides\uc_n06_AuthData.xml
[INFO    ] CWWKE0002I: The kernel started after 2.908 seconds
[INFO    ] CWWKF0007I: Feature update started.
[INFO    ] Aries Blueprint packages not available. So namespaces will not be registered
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
[WARNING ] CWWKZ0014W: The application my-project could not be started as it could not be found at location my-project.war.
[INFO    ] SRVE0169I: Loading Web Module: arquillian-liberty-support.
[INFO    ] SRVE0250I: Web Module arquillian-liberty-support has been bound to default_host.
[INFO    ] SRVE0169I: Loading Web Module: health.
[INFO    ] SRVE0250I: Web Module health has been bound to default_host.
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/arquillian-support/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/health/
[INFO    ] CWWKO0219I: TCP Channel defaultHttpEndpoint has been started and is now listening for requests on host 127.0.0.1  (IPv4: 127.0.0.1) port 9080.
[INFO    ] SESN8501I: The session manager did not find a persistent storage location; HttpSession objects will be stored in the local application server's memory.
[AUDIT   ] CWWKF0012I: The server installed the following features: [beanValidation-2.0, cdi-2.0, el-3.0, jaxrs-2.1, jaxrsClient-2.1, jdbc-4.2, jndi-1.0, json-1.0, jsonp-1.1, localConnector-1.0, mpConfig-2.0, mpHealth-3.0, servlet-4.0, usr:arquillian-support-1.0].
[INFO    ] CWWKF0008I: Feature update completed in 9.795 seconds.
[AUDIT   ] CWWKF0011I: The my-project server is ready to run a smarter planet. The my-project server started in 12.703 seconds.
[INFO    ] SESN0176I: A new session context will be created for application key default_host/health
[INFO    ] SESN0176I: A new session context will be created for application key default_host/arquillian-support
[INFO    ] SESN0172I: The session manager is using the Java default SecureRandom implementation for session ID generation.
[INFO    ] SRVE9103I: A configuration file for a web server plugin was automatically generated for this server at C:\wlp-usr\servers\my-project\logs\state\plugin-cfg.xml.
[INFO    ] SESN0172I: The session manager is using the Java default SecureRandom implementation for session ID generation.
[INFO    ] SRVE0242I: [io.openliberty.microprofile.health.3.0.internal] [/health] [HealthCheckReadinessServlet]: Initialization successful.
[INFO    ] SRVE0242I: [io.openliberty.microprofile.health.3.0.internal] [/health] [HealthCheckServlet]: Initialization successful.
[INFO    ] SRVE0242I: [io.openliberty.microprofile.health.3.0.internal] [/health] [HealthCheckLivenessServlet]: Initialization successful.
[INFO    ] CWWKZ0018I: Starting application 0cd89973-56c1-411b-93d1-546c01680f22.
[INFO    ] CWWKZ0136I: The 0cd89973-56c1-411b-93d1-546c01680f22 application is using the archive file at the C:\wlp-usr\servers\my-project\dropins\0cd89973-56c1-411b-93d1-546c01680f22.war location.
[WARNING ] SRVE9967W: The manifest class path ibmorbtools.jar can not be found in jar file wsjar:file:/C:/dev-env/wlp-usr/servers/my-project/dropins/0cd89973-56c1-411b-93d1-546c01680f22.war!/WEB-INF/lib/tools.jar or its parent.
[WARNING ] SRVE9967W: The manifest class path ibmorbtools.jar can not be found in jar file wsjar:file:/C:/dev-env/wlp-usr/servers/my-project/dropins/0cd89973-56c1-411b-93d1-546c01680f22.war!/WEB-INF/lib/tools.jar or its parent.
[INFO    ] WELD-000900: 3.1.4 (Final)
[INFO    ] HV000001: Hibernate Validator 6.1.7.Final
[INFO    ] SRVE0169I: Loading Web Module: 0cd89973-56c1-411b-93d1-546c01680f22.
[INFO    ] SRVE0250I: Web Module 0cd89973-56c1-411b-93d1-546c01680f22 has been bound to default_host.
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/0cd89973-56c1-411b-93d1-546c01680f22/
[INFO    ] SESN0176I: A new session context will be created for application key default_host/0cd89973-56c1-411b-93d1-546c01680f22
[INFO    ] SESN0172I: The session manager is using the Java default SecureRandom implementation for session ID generation.
[INFO    ] SRVE9103I: A configuration file for a web server plugin was automatically generated for this server at C:\wlp-usr\servers\my-project\logs\state\plugin-cfg.xml.
[AUDIT   ] CWWKZ0001I: Application 0cd89973-56c1-411b-93d1-546c01680f22 started in 12.897 seconds.
[WARNING ] CWWKW1002W: The CDI scope of JAXRS Provider AppParamConverterProvider is javax.enterprise.context.Dependent. Liberty gets the provider instance from CDI.
[WARNING ] CWWKW1002W: The CDI scope of JAXRS Provider ConstraintViolationExceptionMapper is javax.enterprise.context.Dependent. Liberty gets the provider instance from CDI.
[INFO    ] Setting the server's publish address to be /rest/
[INFO    ] SRVE0242I: [0cd89973-56c1-411b-93d1-546c01680f22] [/0cd89973-56c1-411b-93d1-546c01680f22] [br.myPackage.resource.Application]: Initialization successful.
[AUDIT   ] CWWKT0017I: Web application removed (default_host): http://localhost:9080/0cd89973-56c1-411b-93d1-546c01680f22/
[INFO    ] SRVE0253I: [0cd89973-56c1-411b-93d1-546c01680f22] [/0cd89973-56c1-411b-93d1-546c01680f22] [br.myPackage.resource.Application]: Destroy successful.
[AUDIT   ] CWWKZ0009I: The application 0cd89973-56c1-411b-93d1-546c01680f22 has stopped successfully.
[INFO    ] SRVE9103I: A configuration file for a web server plugin was automatically generated for this server at C:\wlp-usr\servers\my-project\logs\state\plugin-cfg.xml.
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 36.663 s <<< FAILURE! - in br.myPackage.resource.MyResourceIT
[ERROR] br.myPackage.resource.MyResourceIT.testBadRequest  Time elapsed: 0.887 s  <<< FAILURE!
java.lang.AssertionError:
Bad Request
Expected: is <200>
     but: was <400>
        at br.myPackage.resource.MyResourceIT.testBadRequest(MyResourceIT.java:67)

O servidor my-project n?o existe.
[ERROR] Test mechanism :: Could not run @AfterSuite
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   MyResourceIT.testBadRequest:67 Bad Request
Expected: is <200>
     but: was <400>
[INFO]
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- maven-failsafe-plugin:3.0.0-M5:verify (default-cli) @ my-project ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:38 min
[INFO] Finished at: 2021-04-24T14:10:23-03:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M5:verify (default-cli) on project my-project: There are test failures.
[ERROR]
[ERROR] Please refer to C:\my-project\target\failsafe-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the forked process
[ERROR] Test mechanism :: Could not run @AfterSuite
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:733)
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:305)
[ERROR]         at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:265)
[ERROR]         at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
[ERROR]         at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
[ERROR]         at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
[ERROR]         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR]         at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR]         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR]         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR]         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR]         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
[ERROR]         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
[ERROR]         at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
[ERROR]         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR]         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
[ERROR]         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
[ERROR]         at java.lang.reflect.Method.invoke(Method.java:508)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

When usrDir property was unavailable, I had to resort to global server.env file, this way:

pom.xml

  <build>
      <plugin>
        <groupId>io.openliberty.tools</groupId>
        <artifactId>liberty-maven-plugin</artifactId>
        <version>3.3.4</version>
        <configuration>
          <serverName>my-project</serverName>
          <configFile>src/main/liberty/server.xml</configFile>
          <configDirectory>src/main/liberty/local</configDirectory>
          <userDirectory>C:/wlp-usr</userDirectory>
          <libertySettingsFolder>src/main/liberty/local/etc</libertySettingsFolder>
        </configuration>
      </plugin>
  </build>

src/main/liberty/local/etc/server.env

WLP_USER_DIR=C:/wlp-usr/

Using this configuration with liberty-arquillian-managed version 1.0.7 still works fine. The problem seems to have roots in usrDir property in arquillian.xml.

UnDeployed application is still in apps/expanded

Issue Overview

After undeploying the arquillian-managed.war under dropins it is still under apps/expanded.
If you start the server again by maven ci start-server the previously deployed arquillian-managed.war is still deployed.

Expected Behaviour

The arquillian-managed.war should be removed from Server completely.

Current Behaviour

The arquillian-managed.war is still deployed.

Steps To Reproduce
  1. Run arquillian test
  2. Look at apps/expanded .. it is still there.

Maven surefire fork error when running large test suites with OpenJ9

Tested with both OpenJ9 8 and OpenJ9 11. Large test suites ( > 1000 tests) with TestNg result in a Maven Surefire error:

Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 255
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (build 1.8.0_265-b01)
Eclipse OpenJ9 VM (build openj9-0.21.0, JRE 1.8.0 Mac OS X amd64-64-Bit Compressed References 20200728_646 (JIT enabled, AOT enabled)
OpenJ9   - 34cf4c075
OMR      - 113e54219
JCL      - c82ff0c20f based on jdk8u265-b01)

This error does occur with HotSpot.

Use java.io.File to concatenate path components

When concatenating path components, care should be taken to introduce path separators ("/") when needed.

In:

String serverConfigDir = getWlpUsrDir() + "servers/" + containerConfiguration.getServerName();

it should be noted that getWlpUsrDir() must return a directory with / appended to it.

Otherwise it may error out with:

Caused by: java.io.FileNotFoundException: C:\dev-env\wlp-usrservers\myserver\server.xml (The system could not find the specified path.)

Ensure consistant behavior between managed and remote containers

Issue Overview

I have noticed some inconsistencies in behavior between the managed and remote container implementations that result in failures when running tests between application servers. Since not all application servers offer a managed container, I would expect most developers to use the remote container by default. So we would want to make sure it performs as well as the managed container.

Below is likely just one example of unexpected behavior using the remote container.

Stackoverflow Issue: https://stackoverflow.com/questions/70177509/use-arquillianresource-to-inject-url-when-deploying-an-enterprisearchive

Expected Behaviour

When deploying an Enterprise Archive with an embedded servlet:

public class SecurityTests extends ArquillianTests {
    @ArquillianResource(SecurityServlet.class)
    URL baseURL;

    @Deployment(testable=false)
    public static EnterpriseArchive createDeployment() {
        WebArchive war = ShrinkWrap.create(WebArchive.class)
                .addPackages(true, SecurityServlet.class.getPackage());
        
        JavaArchive jar = ShrinkWrap.create(JavaArchive.class)
                .addClasses(SecurityTestRemote.class, SecurityTestEjb.class)
                .addAsManifestResource(ContextTests.class.getPackage(), "ejb-jar.xml", "ejb-jar.xml");
        
        EnterpriseArchive ear = ShrinkWrap.create(EnterpriseArchive.class)
                .addAsModules(war, jar)
                .addAsManifestResource(ContextTests.class.getPackage(), "sun-ejb-jar.xml", "sun-ejb-jar.xml");
        
        return ear;
    }
}
@WebServlet("/SecurityServlet")
public class SecurityServlet extends HttpServlet

Each module of the archive is given a random name:

> 681737db-3621-4b1a-b77a-4f571b877126.ear
  > META-INF
  > 5f6d70e5-13f9-4d49-a32f-c7b3138da9fa.war
    > WEB-INF ...
  > 90772573-9202-4c77-b8b9-99b5869dd29f.jar
    > META-INF ...

I would expect the @ArquillianResource(SecurityServlet.class) to return:

http://localhost:8010/5f6d70e5-13f9-4d49-a32f-c7b3138da9fa

Current Behaviour

Instead, I get one of two results.
If I use just @ArquillianResource I get in return http://localhost:8010/681737db-3621-4b1a-b77a-4f571b877126 which is the name of the EAR and not the web module.

If i use @ArquillianResource(SecurityServlet.class) I get an exception:

arquillianBeforeTest(jakarta.enterprise.concurrent.spec.ManagedScheduledExecutorService.security.SecurityTests)  Time elapsed: 4.134 sec  <<< FAILURE!
java.lang.RuntimeException: Could not lookup value for field java.net.URL jakarta.enterprise.concurrent.spec.ManagedScheduledExecutorService.security.SecurityTests.baseURL
    at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:68)
    at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:51)
Caused by: java.lang.RuntimeException: All Providers for type class java.net.URL returned a null value: [org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider@9e28539]
    at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:126)
    at org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:66)
    at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:51)
    at org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:48)

Steps To Reproduce

  1. Run this test on a remote container

Additional Information

server.xml

<featureManager>
  <!-- Features being tested -->
  <feature>jakartaee-9.1</feature>
  <!-- Supporting features -->
  <feature>jndi-1.0</feature> 
  <!-- Features needed for arquillan support -->
  <feature>localConnector-1.0</feature>
  <feature>restConnector-2.0</feature>
  <feature>arquillian-support-jakarta-2.0</feature>
</featureManager>

pom.xml

<dependency>
  <groupId>io.openliberty.arquillian</groupId>
  <artifactId>arquillian-liberty-remote-jakarta-testng</artifactId>
  <version>2.0.2</version>
  <type>pom</type>
  <scope>test</scope>
<dependency>

XML deployment fails if apps directory does not exist

Issue Overview

Using the xml deployment type fails if the apps directory is not pre-created.

Expected Behaviour

The apps directory should be created if it does not exist and the test should run.

Current Behaviour

Test fails with a DeploymentException, caused by a FileNotFoundException when trying to write the archive to a file.

Steps To Reproduce
  1. Create a liberty server, ensure the apps directory does not exist
  2. Configure the container to use this server and to use the xml deployment type.
  3. Try to run a test that deploys an app

Configuration serverName provided is not valid

I've been working with openliberty for a while now, using the following configuration:

<project ...>
  ...
  <artifactId>liberty-it</artifactId>
  ...
  <build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
      <plugin>
        <groupId>io.openliberty.tools</groupId>
        <artifactId>liberty-maven-plugin</artifactId>
        <version>3.3.4</version>
        <configuration>
          <serverName>${project.artifactId}</serverName>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

But then I tried to introduce integration tests with arquillian, but it choked with (EchoicChamberIT is my test case):

[ERROR] Errors: 
[ERROR]   EchoicChamberIT ยป Configuration serverName provided is not valid: 'liberty-it'

The culprit is the validation at:

.

As a workaround I removed the serverName configuration from io.openliberty.tools:liberty-maven-plugin (effectively changing serverName to defaultServer, which complies to the validation above).

Deployment Timeout while waiting for "test" ApplicationMBean

In the former plain Jakarta EE 8 codes, just included some simple CDI codes, the Arquillian liberty managed container worked well.

In the latest days, I am trying to add EJB and JMS samples found OpenLIberty does not follow the default resources rule (DefaultDataSource, DefaultJMSConnectionFactory) as other application servers, and also did not support portable resource configuration eg @JMSDestinationDefinition in codes, etc.

I added a simple ejb branch to taste EJB features on the popular application servers, but OpenLiberty does not work as expected. I have already added DefaultDataSource configuration in the server.xml file.

But I can not make the test passed, and always got an error DeploymentException: Timeout while waiting for "test" ApplicationMBean to reach STARTED. Actual state: STARTING, when running the test:

mvn clean verify -Parq-liberty-managed -Dit.test=BasketEjbTest

I described the issue on StackOverflow, check here and this jms topic.

Webapp descriptor ibm-web-ext.xml should be also used to determine context root

Issue Overview

For EAR deployments, the application.xml is optional since JavaEE 5. Websphere Liberty (and even Traditional) support to define a web archive's context root using the IBM specific web application descriptor file ibm-web-ext.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-ext xmlns:xsi="..." ...>
  <context-root uri="/webshop"/>
</web-ext>

Unfortunately, WLPManagedContainer only looks up the context root in the ear's application xml.
When there is no application.xml found, it falls back to use the archive name as context root.
In our application the context root doesn't match the archive name and changing both is not possible due to compatibility reasons.

Expected Behaviour

Determine the context root of a web application using the application.xml of the EAR deployment, but fallback to use the ibm-webapp-ext.xml if the context root cannot be determined via application.xml.
After that, I would expect a fallback to use the deployment (archive) name.

Current Behaviour

Context root is only determined via application.xml. The descriptor ibm-webapp-ext.xml is not evaluated at all.

Steps To Reproduce
  1. Deploy a webarchive that defines context root (which differs from archive name) using ibm-webapp-ext.xml
  2. Start the application using Arquillian with WLPManagedContainer.
  3. The wrong context root (just the archive name without '.war') is registered at Arquillian (@ArquillianResource delivers wrong context-root in URL)
Additional Information

I got it fixed locally by replacing the WLPManagedContainer.getContextRoot method with these lines:

private String getContextRoot(EnterpriseArchive ear, WebArchive war) throws DeploymentException {
   org.jboss.shrinkwrap.api.Node applicationXmlNode = ear.get("META-INF/application.xml");
   if(applicationXmlNode != null && applicationXmlNode.getAsset() != null) {
	   InputStream input = null;
	   try {
		   input = ear.get("META-INF/application.xml").getAsset().openStream();
		   Document applicationXml = readXML(input);
		   XPath xPath = XPathFactory.newInstance().newXPath();
		   XPathExpression ctxRootSelector = xPath.compile("//module/web[web-uri/text()='"+ war.getName() +"']/context-root");
		   String ctxRoot = ctxRootSelector.evaluate(applicationXml);
		   if(ctxRoot != null && ctxRoot.trim().length() > 0) {
			   return ctxRoot;
		   }
	   } catch (Exception e) {
		   throw new DeploymentException("Unable to retrieve context-root from application.xml");
	   } finally {
		   closeQuietly(input);
	   }
   }
   return getContextRoot(war);
}
   
private String getContextRoot(WebArchive war) throws DeploymentException {
   org.jboss.shrinkwrap.api.Node webExtXmlNode = war.get("WEB-INF/ibm-web-ext.xml");
   if(webExtXmlNode != null && webExtXmlNode.getAsset() != null) {
	   InputStream input = null;
	   try {
		   input = war.get("WEB-INF/ibm-web-ext.xml").getAsset().openStream();
		   Document webExtXml = readXML(input);
		   XPath xPath = XPathFactory.newInstance().newXPath();
		   XPathExpression ctxRootSelector = xPath.compile("//context-root/@uri");
		   String ctxRoot = ctxRootSelector.evaluate(webExtXml);
		   if(ctxRoot != null && ctxRoot.trim().length() > 0) {
			   return ctxRoot;
		   }
	   } catch (Exception e) {
		   throw new DeploymentException("Unable to retrieve context-root from ibm-web-ext.xml");
	   } finally {
		   closeQuietly(input);
	   }
   }
   return createDeploymentName(war.getName());
}

I will prepare a pull request with that fix? Would it be possible for you to review my code and merge it if it is okay?

Thank you very much!

Regards
Christian

Consider offering artifacts that support the Arquillian Junit5 runner

Issue Overview

The current Open Liberty Arquillian artifacts for JUnit:

io.openliberty.arquillian:arquillian-liberty-managed-junit:1.1.8
io.openliberty.arquillian:arquillian-liberty-remote-junit:1.1.8
io.openliberty.arquillian:arquillian-liberty-remote-jakarta-junit:2.1.0
io.openliberty.arquillian:arquillian-liberty-managed-jakarta-junit:2.1.0

All have a common dependency on

org.jboss.arquillian.junit:arquillian-junit-container:1.6.0.Final

More modern tests are being written using Junit5 which require the Arquillian Junit5 Runner:

org.jboss.arquillian.junit5:arquillian-junit5-container:1.7.0.Alpha13
Expected Behaviour

Liberty Arquillian should support the JUnit 5 Runner

Current Behaviour

As-is it does not seem as if Liberty Arquillian supports the JUnit5 Runner

Additional Information

Current workaround:

<dependencyManagement>
    <dependencies>
	<dependency>
		<groupId>org.jboss.arquillian</groupId>
		<artifactId>arquillian-bom</artifactId>
		<version>1.7.0.Alpha13</version>
		<type>pom</type>
		<scope>import</scope>
	</dependency>
	<dependency>
		<groupId>org.junit</groupId>
		<artifactId>junit-bom</artifactId>
		<version>5.9.0</version>
		<type>pom</type>
		<scope>import</scope>
	</dependency>
    </dependencies>
</dependencyManagement>
<dependencies>
    <dependency>
	<groupId>io.openliberty.arquillian</groupId>
	<artifactId>arquillian-liberty-managed-jakarta-junit</artifactId>
	<version>2.1.0</version>
	<type>pom</type>
	<!-- Use Junit5 Runner instead-->
	<exclusions>
		<exclusion>
			<groupId>org.jboss.arquillian.junit</groupId>
			<artifactId>arquillian-junit-container</artifactId>
		</exclusion>
	</exclusions>
    </dependency>
    <dependency>
	<groupId>org.jboss.arquillian.junit5</groupId>
	<artifactId>arquillian-junit5-container</artifactId>
    </dependency>
</dependencies>

Allow server to start on random available ports

It would be nice to allow the server to start on random available ports.

That is relevant in the context of a continuous integration server, because many projects might be using arquillian for integration testing, and many jobs could happen to be running in parallel.

It would be sad if one job failed because "address is alreay in use".
Or even worse: project A exercise its endpoints onto a server brought up by another branch of same project A (and another CI job).

Besides starting on random port, that chosen port must be captured by @ArquillianResource private URI serverURI.

Improve error message when localConnector feature is not installed

Currently when the localConnector-1.0 feature is not installed users will see:
feature definition could not be found for localConnector-1.0
and when Arquillian starts up:

Caused by: org.jboss.arquillian.container.spi.client.container.LifecycleException: Unable to retrieve connector address for localConnector of started VM

We should improve this error message to prompt users to check if the feature is configured in their server.xml or ensure that the feature is installed (and configured).

Investigate removing use of the Attach API

Issue Overview

We use the attach API to get hold of the JMX URL. However, this URL is also written to a file by the localConnector-1.0 feature. We might be able to avoid using the attach API altogether which would simplify the code somewhat.

I think we also use the Attach API to see if the server is already running, so we'd also have to find another way of doing that.

localConnector docs: https://www.ibm.com/support/knowledgecenter/en/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/twlp_admin_localconnector.html

Detect names of servlets from @WebServlet annotation

With the j2eemangement feature no longer being supported for Jakarta EE 9, we need a new way to detect the names of servlets when multiple applications are deployed and we must inject multiple servlets.

See these tests for example uses: https://github.com/OpenLiberty/liberty-arquillian/tree/master/liberty-managed/src/test/java/io/openliberty/arquillian/managed/needsmanagementmbeans

After first scanning for servlets within a web.xml, see #74, we should scan for classes annotated with @WebServlet and use the name property specified. If a servlet name is not explicitly set in the @WebServlet annotation, use the class name.

Liberty reports CWWKZ0059E when ShouldThrowException is used with xml deployment type

Issue Overview

When a test with @ShouldThrowException is run with deploymentType=xml, the following error appears in the liberty log:

[03/07/18 10:03:03:796 BST] 00000093 com.ibm.ws.app.manager.AppMessageHelper                      E CWWKZ0059E: The ftInvalidBulkhead1 application installed from ftInvalidBulkhead1.war has been deleted while it is still configured.

This suggests that the container is deleting the application archive before the application has stopped.

This is slightly odd as it looks the container code does remove the entry from the server.xml and wait for the mbean to disappear before deleting the file, but we're still getting this error from liberty.

Expected Behaviour

This error should not appear.

Steps To Reproduce
  1. Run the microprofile fault tolerance TCK with deploymentType=xml

Arquillian Remote Adapter Not Working with Open Liberty Docker Image

I tried to use Arquillian Remote Adapter with Open Liberty Official Docker Image. Initially got I error related to SSH.

[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.491 s <<< FAILURE! - in com.github.ankurpathak.integration.FilterServletTest
[ERROR] com.github.ankurpathak.integration.FilterServletTest  Time elapsed: 1.479 s  <<< ERROR!
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not determine remote server status : PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at io.openliberty.arquillian.remote.WLPRemoteContainer.start(WLPRemoteContainer.java:87)
        at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
        at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
        at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181)
        at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
        at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
        at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
        at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
        at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71)
        at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23)
        at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19)
        at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
        at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
        at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:326)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:269)
        at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:645)
        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:464)
        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:360)
        at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
        at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)
        at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)
        at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:168)
        at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1148)
        at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1057)
        at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:395)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:396)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:355)
        at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
        at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:359)
        at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:381)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:237)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
        at org.apache.http.client.fluent.Request.internalExecute(Request.java:173)
        at org.apache.http.client.fluent.Executor.execute(Executor.java:262)
        at io.openliberty.arquillian.remote.WLPRestClient.isServerUp(WLPRestClient.java:156)
        at io.openliberty.arquillian.remote.WLPRemoteContainer.start(WLPRemoteContainer.java:69)
        ... 65 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
        at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
        at java.base/sun.security.validator.Validator.validate(Validator.java:264)
        at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
        at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:629)
        ... 91 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
        at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
        at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
        at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
        ... 97 more

Docker Compose Service Content:

Docker Compose:

    liberty:
    image: open-liberty:21.0.0.2-full-java8-openj9
    container_name: liberty
    ports:
      - "9080:9080"
      - "9443:9443" # HTTPS listener
    #    command: configure.sh # use for open-liberty:kernel image.
    #    environment:
    volumes:
      - ./deployments:/config/dropins
      - ./src/test/liberty-remote/server.xml:/liberty/usr/servers/defaultServer/server.xml

Here is server.xml file:

<server description="new server">
    <!-- Enable features -->
    <featureManager>
        <feature>jakartaee-8.0</feature>
        <feature>restConnector-2.0</feature>
    </featureManager>
    <quickStartSecurity userName="admin" userPassword="admin" />
    <ssl id="defaultSSLConfig" trustDefaultCerts="true"/>
    <keyStore id="defaultKeyStore" password="password" />
    <applicationMonitor updateTrigger="mbean" />
    <logging consoleLogLevel="INFO" />
    <remoteFileAccess>
        <writeDir>${server.config.dir}/dropins</writeDir>
    </remoteFileAccess>
    <httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" />

    <!-- Automatically expand WAR files and EAR files -->
    <applicationManager autoExpand="true"/>
</server>

After Above SSH error I imported cert file and imported it in my JRE and SSH Error is gone and I started getting below error:

com.github.ankurpathak.integration.FilterServletTest  Time elapsed: 3.416 s  <<< ERROR!
org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy application to server, server returned response: HttpResponseProxy{HTTP/1.1 400 Bad Request [Date: Sat, 27 Feb 2021 15:31:53 GMT, X-Powered-By: Servlet/4.0, Content-Type: application/json; charset=UTF-8, Content-Language: en-US, Transfer-Encoding: chunked, Connection: Close] [Content-Type: application/json; charset=UTF-8,Content-Length: 9265,Chunked: false]}
        at io.openliberty.arquillian.remote.WLPRemoteContainer.deploy(WLPRemoteContainer.java:141)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:151)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:118)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:239)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:118)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
        at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:71)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:47)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
        at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:92)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:77)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:232)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:212)
        at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:77)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
        at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
        at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:96)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
        at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
        at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
        at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
        at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:89)
        at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:163)
        at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
        at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
        at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
        at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
        at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)

Incorrect deployment exception returned when several apps with the same name are deployed over the lifetime of a server

Issue Overview

When an application fails to deploy, the container scans the log file to work out why it failed. It scans from the start of the log file, looking for lines which either say "myApp started" or "myApp failed to start".

If two apps with the same name are deployed over the course of a test run and the second one fails to deploy, this code will find the log entry for when the first app either deployed successfully or failed to deploy.

Expected Behaviour

When the second app fails to start, the container should identify the correct log line.

Current Behaviour

The container reports the states from the first app.

In my case, an app with the same name had previously deployed successfully. The resulting error was:

org.jboss.arquillian.container.spi.client.container.DeploymentException: Application ftCircuitBreaker started unexpectedly even though it never reached the STARTED state. This should never happen.
	at io.openliberty.arquillian.managed.WLPManagedContainer.throwDeploymentException(WLPManagedContainer.java:1191)
	at io.openliberty.arquillian.managed.WLPManagedContainer.checkApplicationStatus(WLPManagedContainer.java:964)
	at io.openliberty.arquillian.managed.WLPManagedContainer.waitForApplicationTargetState(WLPManagedContainer.java:925)
	at io.openliberty.arquillian.managed.WLPManagedContainer.deploy(WLPManagedContainer.java:420)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:151)

Allow set properties in maven-failsafe-plugin configuration

I tried to set liberty properties(wlpHome) in maven-failsafe-plugin configuration like what I have done in wildfly configuration. But it seems it does not support.

I hope all liberty properties can be configured via environmentVariables and systemProperties, eg in maven-failsafe-plugin or maven-surefire-plugin, or system properties(can be overriden by Maven args) and make the properties config in arquillian.xml is optional.

<configuration>
                            <environmentVariables>
                                <WLP_HOME>${project.build.directory}/wlp</WLP_HOME>
                            </environmentVariables>
                            <systemProperties>
                                <wlpHome>${project.build.directory}/wlp</wlpHome>
                            </systemProperties>
                        </configuration>

It should be possible to specify WLP_USER_DIR as property or environment variable

Issue Overview

For our Java EE application tests, we would like to have the untouched WLP / OpenLiberty distribution centrally located (e.g. in USER_HOME directory) and WLP_USER_DIR within build system's working directory ("target/" for Maven or "build/" for Gradle).

This way we can avoid to download and copy the distribution again and again for each test.

WLP allows to set the WLP_USER_DIR environment variable to decouple the installation (WLP_HOME_DIR) from the user directory.

Since this commit, WLP_USER_DIR as process environment variable is no longer evaluated to determine user directory. I am not sure if this was intended but at least the comments are not consistent:

WLP_USER_DIR can be specified only as a process environment variable or ${wlp.install.dir}/etc/server.env file

WLP_USER_DIR can be specified only in the ${wlp.install.dir}/etc/server.env file

if (!key.equals(WLP_USER_DIR)) { // WLP_USER_DIR can be specified only as a process environment variable
// or ${wlp.install.dir}/etc/server.env file
    try {
       fisServerEnv = new FileInputStream(new File(getServerEnvFilename()));
       ....
    } catch (...)
    }
}
 // Liberty system wide not used for things that would collide across >1 server like LOG_DIR
if (value == null && !key.equals(LOG_DIR)) {
    try {
       fisSystemServerEnv = new FileInputStream(new File(getSystemServerEnvFilename()));
       ...
    } catch (...
    }
    // Process environment variables
    if (value == null && !key.equals(WLP_USER_DIR)) { // WLP_USER_DIR can be specified only in the
                                                      // ${wlp.install.dir}/etc/server.env file
       value = getEnv(key);
    }
}

From my point of view, there should be a way to externally specify WLP_USER_DIR. We cannot set it in ${wlp.install.dir}/etc/server.env, since the value could change for each test setup.

Simplest approach would be to remove the condition !key.equals(WLP_USER_DIR) from the last if-clause that prevents the process environment variable to be evaluated.

Expected Behaviour

WLP_USER_DIR is customizable via test process environment variable

Current Behaviour

WLP_USER_DIR is expected to be WLP_HOME_DIR/usr if not specified in the installation's server.env file.

Steps To Reproduce
  1. Set test process environment variable WLP_HOME_DIR to the WLP user directory to be used (that contains a created server (e.g. named testing))
  2. Arquillian test will fail since server.xml is accessed at WLP_HOME_DIR:
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
...
Caused by: org.jboss.arquillian.container.spi.client.container.DeploymentException: Exception while reading server.xml file.
	at io.openliberty.arquillian.managed.WLPManagedContainer.readServerXML(WLPManagedContainer.java:789)
	at io.openliberty.arquillian.managed.WLPManagedContainer.start(WLPManagedContainer.java:192)
	... 100 more
Caused by: java.io.FileNotFoundException: /home/test-user/.liberty/libertyDist/wlp-javaee7-18.0.0.2/usr/servers/testing/server.xml (No such file or directory)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at io.openliberty.arquillian.managed.WLPManagedContainer.readServerXML(WLPManagedContainer.java:786)
	... 101 more

Additional Information

I will prepare a pull request for that change. Could you please review my PR and check if it would be possible to merge?

  • Another option would be to externalize the WLP_USER_DIR as an optional arquillian.xml property and to override the appropriate environment variable for the ProcessBuilder that starts WLP. Please let me know if I should better provide a PR for that.

Thank you very much!
Christian

Make hostname verification optional

Issue Overview

There is no way to disable hostname verification. We are using this in a test-environment where the subjectAltName is missing from the certificates and hostname verification always fails, even if the truststore contains the appropriate certificates.

Expected Behaviour

A configuration option to disable certificate validation, or at least use HTTP. The httpPort does not seem to be used.

Current Behaviour
  • There is no option to disable certificate verification.
  • There is no option to use HTTP instead of HTTPS.
Steps To Reproduce

Looking at WLPRestClient and WLPRemoteContainerConfiguration we can see that these configuration options are missing.

Additional Information

Opened new PR, feel free to close this if you don't think it belongs here. I'll be using my fork in the meantime but figured I might as well open a PR.

It is impossible to use a custom wlp.usr.dir with arquillian

Hi,

Issue Overview

by any means, it is really complicated to use a custom wlp.usr.dir.

Expected Behaviour

Can set WLP_USER_DIR somewow in pom.xml and/or not use WLP_USER_DIR from environment.

Current Behaviour

When a user sets both WLP_USER_DIR in his personal environment and <userDirectory/> in liberty-maven-plugin is used, liberty-arquillian cannot be pointed easily to the correct directory.

Steps To Reproduce

Environment

WLP_USER_DIR=$HOME/.local/share/wlp-usr

pom.xml

Setting up liberty for arquillian

    <wlp.usr.dir>${project.build.directory}/wlp-usr</wlp.usr.dir>
    <liberty.env.wlp.usr.dir>${wlp.usr.dir}</liberty.env.wlp.usr.dir>

and the plugins

      <!-- configure wlp for arquillian -->
      <plugin>
        <groupId>io.openliberty.tools</groupId>
        <artifactId>liberty-maven-plugin</artifactId>
        <version>3.2</version>
        <extensions>true</extensions>
        <!-- Specify configuration, executions for liberty-maven-plugin -->
        <configuration>
          <serverName>ArquillianManagedServer</serverName>

          <assemblyArtifact>
            <groupId>io.openliberty</groupId>
            <artifactId>openliberty-runtime</artifactId>
            <version>[19.0.0.12,)</version>
            <type>zip</type>
          </assemblyArtifact>

          <serverXmlFile>src/test/liberty/config/server.xml</serverXmlFile>
          <userDirectory>${wlp.usr.dir}</userDirectory>

          <bootstrapProperties>
            <default.http.port>${testServerHttpPort}</default.http.port>
            <default.https.port>${testServerHttpsPort}</default.https.port>
          </bootstrapProperties>

          <skipTestServer>true</skipTestServer>
        </configuration>

        <executions>
          <execution>
            <id>create-server-management</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>create</goal>
            </goals>
          </execution>

          <execution>
            <id>configure-arquillian-xml</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>configure-arquillian</goal>
            </goals>
            <configuration>
              <arquillianProperties>
                <outputToConsole>true</outputToConsole>
              </arquillianProperties>
              <skipIfArquillianXmlExists>true</skipIfArquillianXmlExists>
            </configuration>
          </execution>
        </executions>
      </plugin>

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-dependency-plugin</artifactId>
        <version>3.1.1</version>
        <executions>
          <execution>
            <id>extract-support-feature</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>unpack</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <artifactItems>
            <artifactItem>
              <groupId>io.openliberty.arquillian</groupId>
              <artifactId>arquillian-liberty-support</artifactId>
              <version>1.0.6</version>
              <type>zip</type>
              <classifier>feature</classifier>
              <overWrite>true</overWrite>
              <outputDirectory>${wlp.usr.dir}</outputDirectory>
            </artifactItem>
          </artifactItems>
        </configuration>
      </plugin>

Expected outcome

Arquillian will start the server via WLPManagedContainer.java

Actual outcome

Line breaks are original.

Mar 25, 2020 4:32:56 PM io.openliberty.arquillian.managed.WLPManagedContainer start
FINER: Starting server with command: [$HOME/svn/project/web/rest-v1/target/liberty/wlp/bin/server, run, ArquillianManagedServer]



Server ArquillianManagedServer d
oes not exist.

Known workarounds

None. At least no easy one.

  • I tried liberty.env.wlp.usr.dir, but it will only set a server-specific server.env file.
  • I tried multiple arquillianProperties, but even the java options have no effect because as you can see WLPManagedContainer.java will only read WLP_USER_DIR from either a system-wide server.env or a environment variable.
  • I can unset the global WLP_USER_DIR by setting the jvm option -Dwlp.ignore.user.dir.from.env=true via arquillianProperties in pom.xml, but this will make liberty look in ${project.build.directory}/liberty/usr again, which is kind of correct, I guess.

Working workaround if, and only if maven-resoures-plugin is defined AFTER the liberty-maven-plugin:

<plugin>
        <artifactId>maven-resources-plugin</artifactId>
        <executions>
          <execution>
            <id>copy-global-server.env</id>
            <phase>pre-integration-test</phase>
            <goals>
              <goal>copy-resources</goal>
            </goals>
            <configuration>
              <outputDirectory>${project.build.directory}/liberty/wlp/etc</outputDirectory>
              <resources>
                <resource>
                  <directory>${basedir}/src/test/liberty/etc</directory>
                  <filtering>true</filtering>
                </resource>
              </resources>
            </configuration>
          </execution>
        </executions>
      </plugin>

Proposed solution

WLPManagedContainer cannot look up the pom.xml file for the other plugin's userDirectory property.
So I think the next best thing would be to have the maven-liberty-plugin write a system-wide server.env file in ${project.build.directory}/liberty/etc/server.env.

Is Java EE 8 supported?

Issue Overview

I try to use the liberty-managed container for running test.
I'm using liberty features like jsonb-1.0 and cdi-2.0 that are not compatible with the configuration of the liberty-managed test container.

Unable to load conflicting versions of features "com.ibm.websphere.appserver.javaeeCompatible-6.0" and "com.ibm.websphere.appserver.javaeeCompatible-8.0".  The feature dependency chains that led to the conflict are: com.ibm.websphere.appserver.jsp-2.2 -> com.ibm.websphere.appserver.javaeeCompatible-6.0 and com.ibm.websphere.appserver.jsonb-1.0 -> com.ibm.websphere.appserver.jsonbInternal-1.0 -> com.ibm.websphere.appserver.jsonbImpl-1.0.1 -> com.ibm.websphere.appserver.jsonp-1.1 -> com.ibm.websphere.appserver.jsonpInternal-1.1 -> com.ibm.websphere.appserver.jsonpImpl-1.1.1 -> com.ibm.websphere.appserver.javaeeCompatible-8.0
Expected Behaviour

I can use liberty-managed container to run tests for my Java EE 8 application.

Current Behaviour

Dependency conflict, can't run the tests.

Steps To Reproduce
  1. add jsonb-1.0 to the server.xml features
  2. add the features for the test container
<!-- Enable features -->
<featureManager>
    <feature>jsp-2.2</feature>
    <feature>localConnector-1.0</feature>
    <feature>j2eeManagement-1.1</feature> <!-- Optional, needed to allow injection on ArquillianResources related to servlets -->
    <feature>usr:arquillian-support-1.0</feature> <!-- Optional, needed for reliable reporting of correct DeploymentExceptions -->
</featureManager>
  1. run an arquillian test
Additional Information

Java EE 8 uses servlet-4.0 and this is not supported by arquillian.

Regression: server does not start unless wlpHome ends with a slash

Issue Overview

Since #42 was merged, the server will not start unless wlpHome ends with a slash

This is because the code tries to find the server command by appending bin/server to the end of wlpHome.

Expected Behaviour

Server should start and tests should run

Current Behaviour

Server fails to start with exception:

Caused by: java.io.IOException: Cannot run program "/home/andrew/git/openliberty-ft-20-tck-runner/wlpbin/server": error=2, No such file or directory
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
	at io.openliberty.arquillian.managed.WLPManagedContainer.start(WLPManagedContainer.java:269)
	at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
	at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:65)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:510)
	at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:211)
	at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:298)
	at org.testng.SuiteRunner.run(SuiteRunner.java:261)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.run(TestNG.java:1048)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:293)
	at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:91)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.io.IOException: Cannot run program "/home/andrew/git/openliberty-ft-20-tck-runner/wlpbin/server": error=2, No such file or directory
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1059)
	at io.openliberty.arquillian.managed.WLPManagedContainer.start(WLPManagedContainer.java:224)
	at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
	at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:65)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:510)
	at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:211)
	at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:298)
	at org.testng.SuiteRunner.run(SuiteRunner.java:261)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.run(TestNG.java:1048)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:293)
	at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:91)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.io.IOException: error=2, No such file or directory
	at java.lang.UNIXProcess.forkAndExec(Native Method)
	at java.lang.UNIXProcess.(UNIXProcess.java:291)
	at java.lang.ProcessImpl.start(ProcessImpl.java:167)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1040)
	at io.openliberty.arquillian.managed.WLPManagedContainer.start(WLPManagedContainer.java:224)
	at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:179)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:137)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:133)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:208)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:54)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:64)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:181)
	at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:64)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
	at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:83)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:70)
	at org.jboss.arquillian.testng.Arquillian.arquillianBeforeSuite(Arquillian.java:65)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
	at java.lang.reflect.Method.invoke(Method.java:508)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:510)
	at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:211)
	at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:138)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:298)
	at org.testng.SuiteRunner.run(SuiteRunner.java:261)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.run(TestNG.java:1048)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:293)
	at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:84)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:91)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Steps To Reproduce
  1. Attempt to run a test with wlpHome set to a valid directory with no trailing slash added

Weld BOM has wrong scope

A recent PR introduced

    <!-- WELD classes, these are present in FFDC 
         and are sometimes instances of TCK @ShouldThrow exceptions -->
    <dependency>
      <groupId>org.jboss.weld</groupId>
      <artifactId>weld-core-bom</artifactId>
      <version>3.0.4.Final</version>
      <scope>import</scope>
      <type>pom</type>
    </dependency>

the liberty-managed/pom.xml

I believe this code DOES have the needed effect (in that it enables the load of a
WELD Exception class that is the subclass of a ShouldThrow) but the bom should
only be in a dependancyManagement section of a pom. So I need to do some
more maven learning (e.g. http://www.baeldung.com/spring-maven-bom ) and in the meantime
move/change the dependancy.

CT pointed out that this is flagged up by maven as a bad scope.

This warning normally shoots off the top of my terminal unnoticed:

[WARNING] Some problems were encountered while building the effective model for io.openliberty.arquillian:arquillian-liberty-managed:jar:1.0.0-SNAPSHOT
[WARNING] 'dependencies.dependency.scope' for org.jboss.weld:weld-core-bom:pom must be one of [provided, compile, runtime, test, system] but is 'import'. @ io.openliberty.arquillian:arquillian-liberty-managed:[unknown-version], /Users/hutchig/git/liberty-arquillian/liberty-managed/pom.xml, line 209, column 14

Update plugin to support Arquillian 1.7

Update the plugin to support Arquillian 1.7

  • update relevant packages to jakarta namespace
  • update to arquillian-protocol-servlet-jakarta and the new ArquillianServletRunnerEE9 uri
  • update relevant testenricher packages provided by arquillian-core to corresponding jakarta versions

Arquillian: Add support for Jakarta EE 9

In doing early testing with the new Jakarta EE9-compatible versions of the CDI and Bean Validation TCKs, I've discovered that we need an updated version of liberty-arquillian to support running with EE9 technologies.

At a minimum, I've found the following so far:

  • Update relevant javax package references to jakarta.
  • Support Arquillian 1.7 and arquillian-protocol-servlet-jakarta by deploying applications to the new ArquillianServletRunnerEE9 URI.
  • Note: There will not be a version of the j2eeManagement feature compatible with EE9, so those code paths will not be used in an EE9 environment.

Check whether delete succeeded when undeploying from dropins

Issue Overview

If deleting a file from dropins fails, the exception returned does not identify the cause

Expected Behaviour

If deleting a file from dropins fails, the exception returned to the user should say that it couldn't delete the file

Current Behaviour

If deleting a file from dropins fails, the exception returned to the user is
Caused by: org.jboss.arquillian.container.spi.client.container.DeploymentException: Timeout while waiting for "CDIPropertyNameMatchingTest" ApplicationMBean to reach NOT_INSTALLED. Actual state: STARTED.

Steps To Reproduce
  1. Run a test which deploys an application to dropins
  2. Cause the application file to fail to undeploy (e.g. by file locking on Windows)
Additional Information

We saw this problem when the liberty process had the file locked due to a server bug. Although liberty shouldn't have the application locked, it might make sense to include a wait and retry loop if we can't delete the file.

Server is not stopped at the end of the test run on Windows

Issue Overview

On Windows platform, the container does not stop the server

Expected Behaviour

Server stops

Current Behaviour

Server continues running after the test is over

Steps To Reproduce
  1. Run a test without starting the server beforehand
  2. Check task manager to see that the server is still running after the test is complete
Additional Information

I'm guessing that this was caused by #42 which changed start() to call the bin/server scripts but did not change stop() which still destroys the process started by start().

On *nix systems, terminating the process started as bin/server run is sufficient to signal the server to shut down gracefully.

On Windows, it appears to kill off the cmd.exe process running server.bat but does not kill the child java.exe process which is the actual server

I would try calling server stop instead of trying to kill the process directly.

failsafeUndeployment is unhelpful when using dropins

Issue Overview

When using failsafeUndeployment, if the container is unable to delete the app archive, it doesn't raise an exception and marks the file for deletion at the end of the test.

However, failing to delete the application archive results in the application not stopping, so the test fails saying "application did not stop" with no information about the underlying cause

Expected Behaviour

Either test should not fail, or the failure message should say that the application file could not be deleted.

Current Behaviour

Test fails because the application did not stop

Steps To Reproduce
  1. enable failsafeUndeployment with dropins
  2. use another process to lock application archive file while the test is running

Create nested set of Deployment/Definiton Exceptions from FFDC 'caused by' chain.

Issue to solve problem discussed here:
http://lists.jboss.org/pipermail/weld-dev/2018-April/003664.html
(and here https://wasrtc.hursley.ibm.com:9443/jazz/web/projects/WS-CD#action=com.ibm.team.workitem.viewWorkItem&id=253519)

Currently the container scrapes the message log to support ShouldThrow
Exceptions by creating a single 'cause' exception.
Other containers (e.g. wildfly) support stacks of causal chain exceptions,
for example as we see in out FFDC files and this enables them to pass tests
without individual tweeking for tests.

The accepted practice (as implemented in the Arquillian Core) is to pass a
ShouldThrow if any of the causal chain of exceptions "is a" exception of
the correct type. So this is what we will want to feed it.

Support for EE10

Issue Overview

I'd like to test with still-under-development EE10 features, but the arquillian-support-jakarta-2.0 feature depends on servlet-5.0 and does not tolerate 6.0;

Expected Behaviour

I'd like to fully support development in EE10.

Current Behaviour

So far, EE10 support in Liberty is limited by the feature. It results in a feature manager conflict when using EE10 features like restfulWS-3.1 that depend on servlet-6.0 when the arquillian-support-jakarta-2.0 features depends on servlet-5.0.

Steps To Reproduce
  1. Start a server using a server.xml with both arquillian-support-jakarta-2.0 and restfulWS-3.1.
  2. Check the logs - startup will have failed due to feature conflict.
Additional Information

I'll plan to provide a PR that adds "6.0" to the tolerates list.

Multiple service implementations found (old and new fully qualified Container class)

I know this is a 'working as designed' but I am raising it for documentation purposes

There is a FAT bucket for Liberty:
https://wasrtc.hursley.ibm.com:9443/jazz/web/projects/WS-CD#action=com.ibm.team.build.viewResult&id=_2ug4sH-FEeiACNpEFzHAag&tab=com.ibm.team.build.web.ui.internal.editors.result.test.TestProvider

That failed with:

Caused by: java.lang.IllegalStateException: Multiple service implementations found for interface org.jboss.arquillian.container.spi.client.container.DeployableContainer. org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer, io.openliberty.arquillian.managed.WLPManagedContainer

'''

java.lang.RuntimeException: Arquillian has previously been attempted initialized, but failed. See cause for previous exception at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:103) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Caused by: java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:166) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:103) at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:114) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Caused by: java.lang.reflect.InvocationTargetException: null at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:88) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) at java.lang.reflect.Constructor.newInstance(Constructor.java:437) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:162) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:103) at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:114) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Caused by: org.jboss.arquillian.container.impl.ContainerCreationException: Could not create Container websphere at org.jboss.arquillian.container.impl.LocalContainerRegistry.create(LocalContainerRegistry.java:85) at org.jboss.arquillian.container.impl.client.container.ContainerRegistryCreator.createRegistry(ContainerRegistryCreator.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.ManagerImpl.bindAndFire(ManagerImpl.java:263) at org.jboss.arquillian.core.impl.InstanceImpl.set(InstanceImpl.java:74) at org.jboss.arquillian.config.impl.extension.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.ManagerImpl.start(ManagerImpl.java:288) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.(EventTestRunnerAdaptor.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:88) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) at java.lang.reflect.Constructor.newInstance(Constructor.java:437) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:162) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:103) at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:114) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Caused by: java.lang.IllegalStateException: Multiple service implementations found for interface org.jboss.arquillian.container.spi.client.container.DeployableContainer. org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer, io.openliberty.arquillian.managed.WLPManagedContainer at org.jboss.arquillian.core.impl.loadable.ServiceRegistryLoader.onlyOne(ServiceRegistryLoader.java:74) at org.jboss.arquillian.container.impl.LocalContainerRegistry.create(LocalContainerRegistry.java:76) at org.jboss.arquillian.container.impl.client.container.ContainerRegistryCreator.createRegistry(ContainerRegistryCreator.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.ManagerImpl.bindAndFire(ManagerImpl.java:263) at org.jboss.arquillian.core.impl.InstanceImpl.set(InstanceImpl.java:74) at org.jboss.arquillian.config.impl.extension.ConfigurationRegistrar.loadConfiguration(ConfigurationRegistrar.java:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) at org.jboss.arquillian.core.impl.ManagerImpl.start(ManagerImpl.java:288) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.(EventTestRunnerAdaptor.java:63) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:88) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) at java.lang.reflect.Constructor.newInstance(Constructor.java:437) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:162) at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:103) at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:114) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) ย 
This was caused by editing

https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.microprofile.metrics_fat_tck/publish/tckRunner/tck/pom.xml

To replace

com.ibm.ws.org.jboss.arquillian.container arquillian-wlp-managed-8.5 1.0.0.Final-SNAPSHOT test

with:

       <groupId>io.openliberty.arquillian</groupId>
        <artifactId>arquillian-liberty-managed</artifactId>
        <version>1.0.1</version>

'''
I believe it is caused the FAT bucket pulling in io.astefanutti material via maven and then that in turn is also placing a service loadable classname for
org.jboss.arquillian.container.spi.client.container.DeployableContainer

In the Websphere environment - and arquillian will not work with two service loadable
implementations of this.

[At one point I was wondering if I needed to 'clean' build more - but then remembered the run above
was with a remote build on a virtual machine where everything would be built cleanly].

Missing '/' before 'servers/' in WLPManagedContainer.java#L1440

Offending line:
https://github.com/OpenLiberty/liberty-arquillian/blob/master/liberty-managed/src/main/java/io/openliberty/arquillian/managed/WLPManagedContainer.java#L1440

Issue Overview

It is common to define directories without a trailing '/'.

When setting ${liberty.install.dir}/etc/server.env containing a custom WLP_USER_DIR, then there will be a missing slash, resulting in a path like ${project.output.directory}/wlp-usrservers/servername/server.xml.

Same goes for defining an environment variable WLP_USER_DIR which has the same effect.

Expected Behaviour

one can define
WLP_USER_DIR=/dir

Current Behaviour

must have a trailing slash

Steps To Reproduce

When setting WLP_USER_DIR in ${liberty.install.dir}/etc/server.env
OR
env var WLP_USER_DIR

Additional Information

Offending line:
https://github.com/OpenLiberty/liberty-arquillian/blob/master/liberty-managed/src/main/java/io/openliberty/arquillian/managed/WLPManagedContainer.java#L1440

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.