[JBoss JIRA] (ARQ-1286) Support Warp on Java EE 5 (Servlets 2.5) compliant containers
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1286?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak closed ARQ-1286.
-------------------------------
Release Notes Text: Java EE 5 is considered outdated technology by now. I think it's reasonable to close this issue then.
Resolution: Won't Fix
> Support Warp on Java EE 5 (Servlets 2.5) compliant containers
> -------------------------------------------------------------
>
> Key: ARQ-1286
> URL: https://issues.jboss.org/browse/ARQ-1286
> Project: Arquillian
> Issue Type: Feature Request
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Lukáš Fryč
> Priority: Critical
> Fix For: warp_1.0.0.Beta1
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> Warp is currently focused on Java EE 6 and higher, since it uses {{@WebFilter}} annotation to intercept incoming requests.
> We may decide to support Servlets 2.5 containers as well in case there is enough interest (please vote if you are interested).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-1892) java.util.NoSuchElementException from TestRunner class getTestRunner method
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1892?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak commented on ARQ-1892:
-------------------------------------
Is it still an issue with latest Arquilian [~saurabh_ksa]?
> java.util.NoSuchElementException from TestRunner class getTestRunner method
> ---------------------------------------------------------------------------
>
> Key: ARQ-1892
> URL: https://issues.jboss.org/browse/ARQ-1892
> Project: Arquillian
> Issue Type: Bug
> Components: Base Implementation
> Affects Versions: 1.1.5.Final
> Environment: RSA, WAS 8.x
> Reporter: Saurabh Agarwal
> Priority: Critical
> Attachments: ArquillianSampleTest.java, SampleBean.java, SampleBeanNonCDI.java, arquillian.xml
>
>
> Hi All,
> Upon running test case with Arqullian, I am getting below exception from TestRunner.class in getTest method.
> I am using Servlet 3.0 protocol.
> java.util.NoSuchElementException
> at java.util.LinkedHashMap$AbstractMapIterator.makeNext(LinkedHashMap.java:143)
> at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:201)
> at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:60)
> at org.jboss.arquillian.container.test.spi.util.TestRunners.getTestRunner(TestRunners.java:44)
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:158)
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:125)
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:89)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1230)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:779)
> at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:478)
> at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
> at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1071)
> at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3815)
> at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
> at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:981)
> at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1662)
> at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:453)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:515)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:306)
> at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:277)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
> at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
> at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
> at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
> at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
> at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
> at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
> at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
> at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1702)
> Any help / resolution is much appreciated.
> Attaching required code for reference. JARS list used are as below as not using Maven
> arquillian-config-api-1.1.5.Final.jar
> arquillian-config-impl-base-1.1.5.Final.jar
> arquillian-config-spi-1.1.5.Final.jar
> arquillian-container-impl-base-1.1.5.Final.jar
> arquillian-container-spi-1.1.5.Final.jar
> arquillian-container-test-api-1.1.5.Final.jar
> arquillian-container-test-impl-base-1.1.5.Final.jar
> arquillian-container-test-spi-1.1.5.Final.jar
> arquillian-core-api-1.1.5.Final.jar
> arquillian-core-impl-base-1.1.5.Final.jar
> arquillian-core-spi-1.1.5.Final.jar
> arquillian-junit-container-1.1.5.Final.jar
> arquillian-junit-core-1.1.5.Final.jar
> arquillian-junit-standalone-1.1.5.Final.jar
> arquillian-protocol-jmx-1.1.5.Final.jar
> arquillian-protocol-servlet-1.1.5.Final.jar
> arquillian-test-api-1.1.5.Final.jar
> arquillian-test-impl-base-1.1.5.Final.jar
> arquillian-test-spi-1.1.5.Final.jar
> arquillian-testenricher-cdi-1.1.5.Final.jar
> arquillian-testenricher-ejb-1.1.5.Final.jar
> arquillian-testenricher-initialcontext-1.1.5.Final.jar
> arquillian-testenricher-resource-1.1.5.Final.jar
> arquillian-testng-container-1.1.5.Final.jar
> arquillian-testng-core-1.1.5.Final.jar
> arquillian-testng-standalone-1.1.5.Final.jar
> arquillian-was-remote-8-1.0.0.Final-SNAPSHOT.jar
> junit-4.8.1.jar
> shrinkwrap-api-1.2.2.jar
> shrinkwrap-descriptors-api-base-2.0.0-alpha-5.jar
> shrinkwrap-descriptors-api-javaee-2.0.0-alpha-5.jar
> shrinkwrap-descriptors-impl-base-2.0.0-alpha-5.jar
> shrinkwrap-descriptors-impl-javaee-2.0.0-alpha-5.jar
> shrinkwrap-descriptors-spi-2.0.0-alpha-5.jar
> shrinkwrap-impl-base-1.2.2.jar
> shrinkwrap-spi-1.2.2.jar
> Thanks
> Saurabh
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9
by Marián Macik (JIRA)
[ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.s... ]
Marián Macik updated ARQ-2115:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/arquillian/arquillian-container-was/pull/29
> 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
>
> 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.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9
by Marián Macik (JIRA)
[ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.s... ]
Marián Macik updated ARQ-2115:
------------------------------
Description:
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
was:
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]
> 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
>
> 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.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9
by Marián Macik (JIRA)
[ https://issues.jboss.org/browse/ARQ-2115?page=com.atlassian.jira.plugin.s... ]
Marián Macik updated ARQ-2115:
------------------------------
Description:
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]
was:
Hi, guys,
I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR:
\#### 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
> 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
>
> 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]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2115) Create Arquillian adapter for WebSphere 9
by Marián Macik (JIRA)
Marián Macik created ARQ-2115:
---------------------------------
Summary: 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
Hi, guys,
I have created the Arquillian adapter for WebSphere 9. Here is the summary of the PR:
\#### 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
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2016) Improve the ability to add custom extensions for the containers
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved ARQ-2016.
---------------------------------
Resolution: Done
Done
> Improve the ability to add custom extensions for the containers
> ---------------------------------------------------------------
>
> Key: ARQ-2016
> URL: https://issues.jboss.org/browse/ARQ-2016
> Project: Arquillian
> Issue Type: Feature Request
> Components: OSGi Containers
> Affects Versions: osgi_2.1.0.Final
> Environment: Under Linux, and inside Karaf 4.x
> Reporter: Steve Storck
> Assignee: Thomas Diesler
>
> When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows:
> {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid}
> package org.jboss.arquillian.spock;
> public class ArquillianSputnik extends Sputnik {
> import org.jboss.arquillian.test.spi.TestRunnerAdaptor;
> import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder;
> // Methods and fields omitted for brevity, but you can see that the
> // proper packages are imported
> public void run(RunNotifier notifier) {
> // Code omitted for brevity
> final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build();
> // More code omitted for brevity
> }
> }
> {code}
> {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> public class TestRunnerAdaptorBuilder {
> private static final String DEFAULT_EXTENSION_CLASS =
> "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader";
> private static final String TEST_RUNNER_IMPL_CLASS =
> "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor";
> public static TestRunnerAdaptor build() {
> // omitted lines for brevity
> ManagerBuilder builder = ManagerBuilder.from()
> .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS));
> return SecurityActions.newInstance(
> TEST_RUNNER_IMPL_CLASS,
> new Class<?>[] {ManagerBuilder.class},
> new Object[] {builder},
> TestRunnerAdaptor.class);
> }
> }
> {code}
> {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> final class SecurityActions {
> static <T> T newInstance(final String className,
> final Class<?>[] argumentTypes,
> final Object[] arguments,
> final Class<T> expectedType) {
> @SuppressWarnings("unchecked")
> Class<T> implClass = (Class<T>) loadClass(className);
> if (!expectedType.isAssignableFrom(implClass)) {
> throw new RuntimeException("Loaded class " +
> className +
> " is not of expected type " +
> expectedType);
> }
> return newInstance(implClass, argumentTypes, arguments);
> }
> }
> {code}
> I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own.
> Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2016) Improve the ability to add custom extensions for the containers
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reassigned ARQ-2016:
-----------------------------------
Assignee: Thomas Diesler
> Improve the ability to add custom extensions for the containers
> ---------------------------------------------------------------
>
> Key: ARQ-2016
> URL: https://issues.jboss.org/browse/ARQ-2016
> Project: Arquillian
> Issue Type: Feature Request
> Components: OSGi Containers
> Affects Versions: osgi_2.1.0.Final
> Environment: Under Linux, and inside Karaf 4.x
> Reporter: Steve Storck
> Assignee: Thomas Diesler
>
> When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows:
> {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid}
> package org.jboss.arquillian.spock;
> public class ArquillianSputnik extends Sputnik {
> import org.jboss.arquillian.test.spi.TestRunnerAdaptor;
> import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder;
> // Methods and fields omitted for brevity, but you can see that the
> // proper packages are imported
> public void run(RunNotifier notifier) {
> // Code omitted for brevity
> final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build();
> // More code omitted for brevity
> }
> }
> {code}
> {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> public class TestRunnerAdaptorBuilder {
> private static final String DEFAULT_EXTENSION_CLASS =
> "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader";
> private static final String TEST_RUNNER_IMPL_CLASS =
> "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor";
> public static TestRunnerAdaptor build() {
> // omitted lines for brevity
> ManagerBuilder builder = ManagerBuilder.from()
> .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS));
> return SecurityActions.newInstance(
> TEST_RUNNER_IMPL_CLASS,
> new Class<?>[] {ManagerBuilder.class},
> new Object[] {builder},
> TestRunnerAdaptor.class);
> }
> }
> {code}
> {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> final class SecurityActions {
> static <T> T newInstance(final String className,
> final Class<?>[] argumentTypes,
> final Object[] arguments,
> final Class<T> expectedType) {
> @SuppressWarnings("unchecked")
> Class<T> implClass = (Class<T>) loadClass(className);
> if (!expectedType.isAssignableFrom(implClass)) {
> throw new RuntimeException("Loaded class " +
> className +
> " is not of expected type " +
> expectedType);
> }
> return newInstance(implClass, argumentTypes, arguments);
> }
> }
> {code}
> I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own.
> Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months
[JBoss JIRA] (ARQ-2016) Improve the ability to add custom extensions for the containers
by Cristina González castellano (JIRA)
[ https://issues.jboss.org/browse/ARQ-2016?page=com.atlassian.jira.plugin.s... ]
Cristina González castellano commented on ARQ-2016:
---------------------------------------------------
Hello!,
We have adapt the Arquillian OSGi Extension so it can use custom extensions, now we are using it sucessfully in the Arquillian Liferay Extension.
The idea that we have implemented is:
1. The Arquillian OSGi Bundle is automatically generated (with all the extensions that are declared in the classpath). (This is done only once)
2. For every test:
2.1. The Arquillian OSGi Bundle is installed.
2.2. The test deployment is installed without any enhacement.
2.3. A fragment for the Arquillian OSGI Bundle that contains only the test class is generated and installed.
2.4 The tests are executed
2.5 All the previously installed bundle are uninstalled.
We have created a pull (https://github.com/arquillian/arquillian-container-osgi/pull/51) were you can check the changes. We think that this maybe can be usefull for someone. Maybe it would be interesting try to merge it with the current Arquillian OSGi Container.
What do you think? If you need more information, please, let us know.
Thanks!
> Improve the ability to add custom extensions for the containers
> ---------------------------------------------------------------
>
> Key: ARQ-2016
> URL: https://issues.jboss.org/browse/ARQ-2016
> Project: Arquillian
> Issue Type: Feature Request
> Components: OSGi Containers
> Affects Versions: osgi_2.1.0.Final
> Environment: Under Linux, and inside Karaf 4.x
> Reporter: Steve Storck
>
> When the arquillian-container-osgi extension is deployed, it also deploys the arquillian-osgi-bundle. This bundle exposes a few APIs, but it contains (and does not expose) some of the implementation and SPI packages. This effectively results in only being able to use the provided JUnitBundleTestRunner extension. I want to use the arquillian-testrunner-spock extension, but it always fails because I have to deploy the test SPI bundle with my test jar, and it conflicts with those packages that the arquillian-osgi-bundle uses internally. This causes an exception to be thrown that complains that the EventTestRunnerAdaptor implementation is not an instance of the TestRunnerAdaptor interface. The chain of events that results in the exception is as follows:
> {code:java|title=ArquillianSputnik.java (arquillian-testrunner-spock)|borderStyle=solid}
> package org.jboss.arquillian.spock;
> public class ArquillianSputnik extends Sputnik {
> import org.jboss.arquillian.test.spi.TestRunnerAdaptor;
> import org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder;
> // Methods and fields omitted for brevity, but you can see that the
> // proper packages are imported
> public void run(RunNotifier notifier) {
> // Code omitted for brevity
> final TestRunnerAdaptor adaptor = TestRunnerAdaptorBuilder.build();
> // More code omitted for brevity
> }
> }
> {code}
> {code:java|title=EventTestRunnerAdaptorBuilder.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> public class TestRunnerAdaptorBuilder {
> private static final String DEFAULT_EXTENSION_CLASS =
> "org.jboss.arquillian.core.impl.loadable.LoadableExtensionLoader";
> private static final String TEST_RUNNER_IMPL_CLASS =
> "org.jboss.arquillian.test.impl.EventTestRunnerAdaptor";
> public static TestRunnerAdaptor build() {
> // omitted lines for brevity
> ManagerBuilder builder = ManagerBuilder.from()
> .extension(SecurityActions.loadClass(DEFAULT_EXTENSION_CLASS));
> return SecurityActions.newInstance(
> TEST_RUNNER_IMPL_CLASS,
> new Class<?>[] {ManagerBuilder.class},
> new Object[] {builder},
> TestRunnerAdaptor.class);
> }
> }
> {code}
> {code:java|title=SecurityActions.java (arquillian-core test/spi)|borderStyle=solid}
> package org.jboss.arquillian.test.spi;
> final class SecurityActions {
> static <T> T newInstance(final String className,
> final Class<?>[] argumentTypes,
> final Object[] arguments,
> final Class<T> expectedType) {
> @SuppressWarnings("unchecked")
> Class<T> implClass = (Class<T>) loadClass(className);
> if (!expectedType.isAssignableFrom(implClass)) {
> throw new RuntimeException("Loaded class " +
> className +
> " is not of expected type " +
> expectedType);
> }
> return newInstance(implClass, argumentTypes, arguments);
> }
> }
> {code}
> I think that the best solution would be to completely decouple the JUnitTestRunner from the container modules, or at the very least, it would be good to change the <_exportcontents> to export most (or all) of the embedded dependency packages so that users can make use of other extensions, or build their own.
> Edit: After some more thought, it would be really nice to make test extensions loadable (with a default if it is unspecified, of course). I don't know enough about the code base (yet) to say if it would be best to do this via an annotation, or if pluggability would be better leveraged somewhere else in the framework.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 11 months