[JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2115:
--------------------------------
Fix Version/s: was_1.0.0.CR1
(was: was_1.0.0.next)
> Create Arquillian adapter for WebSphere 9
> -----------------------------------------
>
> Key: ARQ-2115
> URL: https://issues.jboss.org/browse/ARQ-2115
> Project: Arquillian
> Issue Type: Feature Request
> Components: WebSphere Containers
> Reporter: Marián Macik
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.CR1
>
>
> Hi, guys,
> I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR [1]:
> \#### Short description of what this resolves:
> Hi, guys,
> my name is Marian Macik and I work at Red Hat as QE Engineer on [jBPM|https://github.com/kiegroup/jbpm] project. This PR introduces Arquillian container adapter for WebSphere 9. We have been using it at Red Hat in our QE automation for about two months without any issues. It is copied from adapter for WebSphere 8.5 (as WebSphere 8.5 was copied from WebSphere 8). There were only some minor changes when it comes to system paths pointing at WebSphere dependencies (jgss-provider and ws-admin-client).
> However, since WebSphere 9, wsadmin is using jython27 by default. Jython21 is still supported and to use jython21, 'com.ibm.ws.admin.client.forJython21_9.0.jar' should be used. Moreover, the new wsadmin jar has additional libraries which are not used by Arquillian (such as Python JSR 223 implementation) and might cause issues when deploying and running tests. If this happens, simply override this property with jython21 jar:
> {code}
> -Dws_admin_client_jar_name=com.ibm.ws.admin.client.forJython21_9.0.jar
> {code}
> I added this property because the new jython27 wsadmin implementation was causing issues since it loaded unwanted classes on the classpath. Of course, by default the new jython27 wsadmin is used, override is optional.
> I have also run the enclosed tests with my own arquillian.xml and they have passed.
> Thanks,
> Marian
> [1] https://github.com/arquillian/arquillian-container-was/pull/29
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ARQ-2131) Fix for multiple JVM arguments not released
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2131?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2131:
--------------------------------
Fix Version/s: was_1.0.0.CR1
(was: was_1.0.0.next)
> Fix for multiple JVM arguments not released
> -------------------------------------------
>
> Key: ARQ-2131
> URL: https://issues.jboss.org/browse/ARQ-2131
> Project: Arquillian
> Issue Type: Bug
> Components: WebSphere Containers
> Environment: {code}arquillian-container-was-1.0.0.Beta2{code}
> {{arquillian.xml}} snippet:
> {code:xml} <container qualifier="liberty-ci-managed">
> <configuration>
> <property name="deployType">xml</property>
> <property name="javaVmArguments">-Dsetting1=x -Dsetting2=y</property>
> </configuration>
> </container>{code}
> Reporter: Benjamin Marwell
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.CR1
>
>
> Hello,
> h2. expected output
> Process started with (from Debug):
> {{FINER: Starting server with command: [java, -Dsetting1=x, -Dsetting2=y, -javaagent:lib/bootstrap-agent.jar, -jar, lib/ws-launch.jar, defaultServer]}}
> h2. actual output
> note the missing comma betweed setting1 and setting2:
> {{FINER: Starting server with command: [java, -Dsetting1=x -Dsetting2=y, -javaagent:lib/bootstrap-agent.jar, -jar, lib/ws-launch.jar, defaultServer]}}
> h2. Solution
> Already exists. This commit is currently not in a release:
> https://github.com/arquillian/arquillian-container-was/commit/a1a77fe9241...
> What can't be seen from here: this commit is needed to have multiple JVM args. Otherwise all jvm args are concatenated into a single String.
> So, the bug is fixed in trunk, but not released.
> h2. Proposed test case
> It is also missing a test case.
> Please add a test case with two or more {{-D}}-Parameters and check in your servlet if they are set.
> Thank you very much!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ARQ-2152) Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2152?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2152:
--------------------------------
Fix Version/s: was_1.0.0.CR1
> Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container
> ----------------------------------------------------------------------------------------------
>
> Key: ARQ-2152
> URL: https://issues.jboss.org/browse/ARQ-2152
> Project: Arquillian
> Issue Type: Feature Request
> Components: WebSphere Containers
> Environment: Testing Microprofile TCKs on WebSphere Liberty
> (Apologies for setting the priority.)
> (Apologies if the version is incorrect for https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma...
> Reporter: Gordon Hutchison
> Assignee: Gerhard Poul
> Priority: Minor
> Fix For: was_1.0.0.CR1
>
>
> (I have to thank my colleague Kevin Grigorenko for this patch which I integrated into
> my local clone. The text below is pasted from text written by him: )
> "Added support for injecting a Tracer into the TCK: For the CDI injection to work, the TCK application's classloader must be configured with apiTypeVisibility="spec, ibm-api, third-party". The WAS Arquillian container's default deployType is dropins and I couldn't find a way to configure the classloader for that. The WAS Arquiallian container also supports deployType=xml which puts the WAR into apps and dynamically adds configuration to Liberty's server.xml with the <application /> element and some sub-elements. I forked that code to also add support for apiTypeVisibility and also submitted a pull request. Now, running with that fork and specifying <property name="deployType">xml</property> and <property name="apiTypeVisibility">spec, ibm-api, third-party</property> in mpOpentracingTckRunner/tck/src/test/resources/arquillian.xml allows the TCK to inject the Tracer."
> This WLP feature is discussed here:
> https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websp...
> I have Kevin's code patch that does this and am only raising this issue
> in order to reference it in a pull request I am going to make
> at
> https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma...
> I have checked with Kevin that he is happy for me to do this:
> (On IBM Sametime)
> gordon_hutchison(a)uk.ibm.com - Gordon Hutchison/UK/IBM:
> 4:17:28 PM: Hi Kevin, is it OK with you if I create an issue and then a PR to integrate the 'apiTypeVisibility' change you did to the public upstream repo?
> Kevin GRIGORENKO:
> 4:17:54 PM: Yes, absolutely. Thanks very much!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ARQ-2001) Log status code in WLPRestClient.isServerUp()
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2001?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2001:
--------------------------------
Fix Version/s: was_1.0.0.CR1
(was: was_1.0.0.next)
> Log status code in WLPRestClient.isServerUp()
> ---------------------------------------------
>
> Key: ARQ-2001
> URL: https://issues.jboss.org/browse/ARQ-2001
> Project: Arquillian
> Issue Type: Enhancement
> Components: WebSphere Containers
> Reporter: Paul Holding
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.CR1
>
>
> The WLPRestClient.isServerUp() method doesn't log the status code returned when the following line of code is executed
> {code:java}
> HttpResponse result = executor.execute(Request.Get(hostName)).returnResponse();
> {code}
> The lack of logging makes is impossible to tell why the isServerUp() check failure occurred and the only information returned is a LifecycleException thrown by WLPRemoteContainer with the text "Remote server is not started". This can be misleading as the server may be up but something else is wrong such as an authentication failure.
> Adding something similar to the logging in WLPRestClient.deploy(File archive) would allow the HTTP status code to be recorded and make troubleshooting a lot easier.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ARQ-2152) Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2152?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2152:
--------------------------------
Affects Version/s: (was: was_1.0.0.next)
> Add support for setting 'apiTypeVisibility' in Websphere Liberty Application Server Container
> ----------------------------------------------------------------------------------------------
>
> Key: ARQ-2152
> URL: https://issues.jboss.org/browse/ARQ-2152
> Project: Arquillian
> Issue Type: Feature Request
> Components: WebSphere Containers
> Environment: Testing Microprofile TCKs on WebSphere Liberty
> (Apologies for setting the priority.)
> (Apologies if the version is incorrect for https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma...
> Reporter: Gordon Hutchison
> Assignee: Gerhard Poul
> Priority: Minor
> Fix For: was_1.0.0.CR1
>
>
> (I have to thank my colleague Kevin Grigorenko for this patch which I integrated into
> my local clone. The text below is pasted from text written by him: )
> "Added support for injecting a Tracer into the TCK: For the CDI injection to work, the TCK application's classloader must be configured with apiTypeVisibility="spec, ibm-api, third-party". The WAS Arquillian container's default deployType is dropins and I couldn't find a way to configure the classloader for that. The WAS Arquiallian container also supports deployType=xml which puts the WAR into apps and dynamically adds configuration to Liberty's server.xml with the <application /> element and some sub-elements. I forked that code to also add support for apiTypeVisibility and also submitted a pull request. Now, running with that fork and specifying <property name="deployType">xml</property> and <property name="apiTypeVisibility">spec, ibm-api, third-party</property> in mpOpentracingTckRunner/tck/src/test/resources/arquillian.xml allows the TCK to inject the Tracer."
> This WLP feature is discussed here:
> https://www.ibm.com/support/knowledgecenter/en/SSEQTP_8.5.5/com.ibm.websp...
> I have Kevin's code patch that does this and am only raising this issue
> in order to reference it in a pull request I am going to make
> at
> https://github.com/arquillian/arquillian-container-was/tree/master/wlp-ma...
> I have checked with Kevin that he is happy for me to do this:
> (On IBM Sametime)
> gordon_hutchison(a)uk.ibm.com - Gordon Hutchison/UK/IBM:
> 4:17:28 PM: Hi Kevin, is it OK with you if I create an issue and then a PR to integrate the 'apiTypeVisibility' change you did to the public upstream repo?
> Kevin GRIGORENKO:
> 4:17:54 PM: Yes, absolutely. Thanks very much!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ARQ-2051) Add ability to add localconnector feature automatically to server.xml
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2051?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2051:
--------------------------------
Fix Version/s: was_1.0.0.CR1
> Add ability to add localconnector feature automatically to server.xml
> ---------------------------------------------------------------------
>
> Key: ARQ-2051
> URL: https://issues.jboss.org/browse/ARQ-2051
> Project: Arquillian
> Issue Type: Feature Request
> Components: WebSphere Containers
> Affects Versions: was_1.0.0.Beta2
> Reporter: arjan tijms
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.CR1
>
>
> For the managed container for Liberty to connect to a liberty instance, the {{localConnector-1.0}} feature needs to be present in {{server.xml}}.
> This is somewhat of an obstacle when using a CI managed Liberty, where a Liberty instance is downloaded and installed from Maven during the test. Following the work done in ARQ-1729 it should be relatively easy to add this {{localConnector-1.0}} feature to {{server.xml}}.
> I would like to propose adding a new boolean to the configuration for the managed Liberty container, and when set to true the Arquillian container will add the mentioned feature and will thus be able to start Liberty without requiring the user to modify the installation first.
> (I'll look into doing a PR for this)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (ARQ-2121) wlp-managed extension
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-2121?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-2121:
--------------------------------
Fix Version/s: was_1.0.0.CR1
(was: was_1.0.0.next)
> wlp-managed extension
> ---------------------
>
> Key: ARQ-2121
> URL: https://issues.jboss.org/browse/ARQ-2121
> Project: Arquillian
> Issue Type: Feature Request
> Components: WebSphere Containers
> Affects Versions: 1.0.0.Beta1
> Reporter: Christian Connert
> Assignee: Gerhard Poul
> Fix For: was_1.0.0.CR1
>
> Attachments: wlp.patch
>
>
> Hi guys,
> I did some work on the wlp-managed container which I would like to share with you:
> # Support for multiple JVM arguments
> # Support for different context roots (multi war projects)
> # Security configuration for deployed applications
> # And last but not least fail-safe undeployment (xml) -> seems to be an issue when running the wlp within windows and the Oracle JVM
> Hopfully you find my contribution usefule and will apply the attached patch.
> Cheers
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months