April 2016 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1213) Add support for GlassFish 3.0 container

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-1213?page=com.atlassian.jira.plugin.s... ] Aslak Knutsen commented on ARQ-1213: ------------------------------------ I would say no > Add support for GlassFish 3.0 container > --------------------------------------- > > Key: ARQ-1213 > URL: https://issues.jboss.org/browse/ARQ-1213 > Project: Arquillian > Issue Type: Feature Request > Components: GlassFish Containers > Reporter: Vineet Reynolds > Priority: Minor > > The RESTful admin API provided by GlassFish 3.0 does not provide all the REST resources that are currently used by the GlassFish 3.1 adapter. Hence, the 3.1 adapter is not backward compatible with a GlassFish 3.0 instance. > Additionally, the message formats returned by the REST resources of GF 3.0 are different from the ones returned by GF 3.1, hence requiring different parsing semantics. > We must therefore implement a separate adapter to support GlassFish 3.0, that either uses the RESTful Admin APIs available in 3.0, or a supported API like JSR-88. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-77) Support @EJB injection with proper semantics

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/ARQ-77?page=com.atlassian.jira.plugin.sys... ] Aslak Knutsen commented on ARQ-77: ---------------------------------- No, EJB injection outside of a CDI enabled deployment is still based on guessing names. But only relevant to older containers as CDI is enabled by default in EE7 > Support @EJB injection with proper semantics > -------------------------------------------- > > Key: ARQ-77 > URL: https://issues.jboss.org/browse/ARQ-77 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers, JBoss AS Containers, OpenEJB Containers, Packaging Enricher SPI > Affects Versions: 1.0.0.Alpha1, 1.0.0.Alpha2 > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > Priority: Critical > > Tests should be able to have class or instance members injected according to @EJB semantics, avoiding the need for lookup code. The prototype is currently in the OpenEJB integration module, but really we should have some EJB 3.1 Global JNDI syntax compatible resolvers (which need an EJB name, module name, app name, and business interface name). Note that portable JNDI is under java:global, so only accessible to local JVMs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1566) NPE in GlassFishClientService when connecting to a ssl only glassfish

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1566?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak reassigned ARQ-1566: ----------------------------------- Assignee: Bartosz Majsak > NPE in GlassFishClientService when connecting to a ssl only glassfish > --------------------------------------------------------------------- > > Key: ARQ-1566 > URL: https://issues.jboss.org/browse/ARQ-1566 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers > Affects Versions: glassfish_1.0.0.CR4 > Reporter: Daniel G > Assignee: Bartosz Majsak > > When connecting to a remote-glassfish that has no http port open > {noformat:title=related domain.xml excerpt} > <network-listeners> > <network-listener port="${HTTP_LISTENER_PORT}" enabled="false" protocol="http-listener-1" transport="tcp" name > ="http-listener-1" thread-pool="http-thread-pool"></network-listener> > ... > {noformat} > the test-startup crashes with a NullPointerException. > {noformat} > java.lang.NullPointerException: null > at java.util.regex.Matcher.getTextLength(Matcher.java:1234) > at java.util.regex.Matcher.reset(Matcher.java:308) > at java.util.regex.Matcher.<init>(Matcher.java:228) > at java.util.regex.Pattern.matcher(Pattern.java:1088) > at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.getPortValue(GlassFishClientService.java:673) > at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.access$500(GlassFishClientService.java:41) > at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService$ClusterServer.getNodeAddressList(GlassFishClientService.java:880) > at org.jboss.arquillian.container.glassfish.clientutils.GlassFishClientService.startUp(GlassFishClientService.java:133) > at org.jboss.arquillian.container.glassfish.CommonGlassFishManager.start(CommonGlassFishManager.java:72) > at org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployableContainer.start(GlassFishRestDeployableContainer.java:59) > at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255) > at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > {noformat} > so i forked the build (https://github.com/dgeissl/arquillian-container-glassfish.git) and fixed the corresponding codelines. > to finaly see that the basic https support is missing in Arquillian, cause now i get this exception: > {noformat} > java.lang.IllegalStateException: Error launching test MyTest public void MyTest.testMe() > at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:103) > at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:120) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > ... > Caused by: java.net.SocketException: Unexpected end of file from server > at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) > at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) > at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) > at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) > at java.net.HttpURLConnection.getResponseCode(Unknown Source) > at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:183) > at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.executeWithRetry(ServletMethodExecutor.java:121) > at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:99) > ... 75 more > {noformat} > So the basic NPE cause can be fixed but for the https support we need core changes right? > Like mentioned in ARQ-643 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1383) Support deployment of container wide resource.xml in GlassFish Managed and Remote

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1383?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak reassigned ARQ-1383: ----------------------------------- Assignee: Bartosz Majsak > Support deployment of container wide resource.xml in GlassFish Managed and Remote > ---------------------------------------------------------------------------------- > > Key: ARQ-1383 > URL: https://issues.jboss.org/browse/ARQ-1383 > Project: Arquillian > Issue Type: Feature Request > Components: GlassFish Containers > Affects Versions: glassfish_1.0.0.CR4 > Reporter: Aslak Knutsen > Assignee: Bartosz Majsak > Fix For: glassfish_1.0.0.Final > > > As a User I would like to deploy Container wide resources > Given a Reference to a resource.xml file in ContainerConfiguration > When the Container starts up > Then the resource.xml should be deployed > When the Container shuts down > Then the resource.xml should be undeployed > This is similar to how GlassFish Embedded works. > Configuration: https://github.com/arquillian/arquillian-container-glassfish/blob/master/... > Container Impl: https://github.com/arquillian/arquillian-container-glassfish/blob/master/... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1212) Add support for GlassFish 2.x containers

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1212?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak commented on ARQ-1212: ------------------------------------- Is this issue still relevant? > Add support for GlassFish 2.x containers > ---------------------------------------- > > Key: ARQ-1212 > URL: https://issues.jboss.org/browse/ARQ-1212 > Project: Arquillian > Issue Type: Feature Request > Components: GlassFish Containers > Reporter: Vineet Reynolds > Priority: Minor > > There has been atleast one request to support the GlassFish 2.x container. Since the RESTful admin API used by the current GlassFish adapter is available only since 3.0, we'll need to implement support for 2.x using a different mechanism (possibly using JSR-88 APIs). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-77) Support @EJB injection with proper semantics

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-77?page=com.atlassian.jira.plugin.sys... ] Bartosz Majsak commented on ARQ-77: ----------------------------------- Spring cleaning - is it still relevant? Seems to me like fixed ages ago. Can we close this issue? > Support @EJB injection with proper semantics > -------------------------------------------- > > Key: ARQ-77 > URL: https://issues.jboss.org/browse/ARQ-77 > Project: Arquillian > Issue Type: Bug > Components: GlassFish Containers, JBoss AS Containers, OpenEJB Containers, Packaging Enricher SPI > Affects Versions: 1.0.0.Alpha1, 1.0.0.Alpha2 > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > Priority: Critical > > Tests should be able to have class or instance members injected according to @EJB semantics, avoiding the need for lookup code. The prototype is currently in the OpenEJB integration module, but really we should have some EJB 3.1 Global JNDI syntax compatible resolvers (which need an EJB name, module name, app name, and business interface name). Note that portable JNDI is under java:global, so only accessible to local JVMs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1213) Add support for GlassFish 3.0 container

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1213?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak commented on ARQ-1213: ------------------------------------- Do we still consider this issue relevant? > Add support for GlassFish 3.0 container > --------------------------------------- > > Key: ARQ-1213 > URL: https://issues.jboss.org/browse/ARQ-1213 > Project: Arquillian > Issue Type: Feature Request > Components: GlassFish Containers > Reporter: Vineet Reynolds > Priority: Minor > > The RESTful admin API provided by GlassFish 3.0 does not provide all the REST resources that are currently used by the GlassFish 3.1 adapter. Hence, the 3.1 adapter is not backward compatible with a GlassFish 3.0 instance. > Additionally, the message formats returned by the REST resources of GF 3.0 are different from the ones returned by GF 3.1, hence requiring different parsing semantics. > We must therefore implement a separate adapter to support GlassFish 3.0, that either uses the RESTful Admin APIs available in 3.0, or a supported API like JSR-88. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1282) TestNG @DataProvider is fully invoked for each record

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1282?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak reassigned ARQ-1282: ----------------------------------- Assignee: Bartosz Majsak > TestNG @DataProvider is fully invoked for each record > ----------------------------------------------------- > > Key: ARQ-1282 > URL: https://issues.jboss.org/browse/ARQ-1282 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Affects Versions: 1.0.3.Final > Reporter: Karel Cemus > Assignee: Bartosz Majsak > Attachments: ArquillianDataProvider.java, FlightServiceTest.java > > > h2. Expected behavior > TestNG defines @DataProvider annotation to allow single method to perform multiple test cases. Provider method annotated with @DataProvider returns an array of arrays, each containing one test case. These parameters are given to the target method as input parameters. By the definition, the total count of performed test by single method is equal to number of test cases in related data provider. > h2. Actual behavior > Using TestNG under Arquillian framework makes this functionality buggy. Although the client (maven, IDE, etc.) thinks, that the total number of invoked test is correct, it is not. When we take a look into server's log, we can see that for each single test case it invoked full set of all test cases. It means, that in the end the amount of performed tests is equal to expected count squared. Such behaviour is not only slow but also in some cases it doesn't work and it makes tests to fail. > h2. Example > {code:java} > @DataProvider > public Object[][] sumProvider() { > return new Object[][]{ > new Object[]{ 0, 0, 0 }, > new Object[]{ 1, 1, 2 }, > new Object[]{ 1, 5, 6 }, > new Object[]{ 5, 1, 6 } > }; > } > {code} > h3. Expected output in server log > {quote} > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > {quote} > h3. Actual output > {quote} > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1282) TestNG @DataProvider is fully invoked for each record

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-1282?page=com.atlassian.jira.plugin.s... ] Bartosz Majsak commented on ARQ-1282: ------------------------------------- This issue affects pretty much any other data-driven tests, for example Spock test runner. I'm looking at it. > TestNG @DataProvider is fully invoked for each record > ----------------------------------------------------- > > Key: ARQ-1282 > URL: https://issues.jboss.org/browse/ARQ-1282 > Project: Arquillian > Issue Type: Bug > Components: JBoss AS Containers > Affects Versions: 1.0.3.Final > Reporter: Karel Cemus > Attachments: ArquillianDataProvider.java, FlightServiceTest.java > > > h2. Expected behavior > TestNG defines @DataProvider annotation to allow single method to perform multiple test cases. Provider method annotated with @DataProvider returns an array of arrays, each containing one test case. These parameters are given to the target method as input parameters. By the definition, the total count of performed test by single method is equal to number of test cases in related data provider. > h2. Actual behavior > Using TestNG under Arquillian framework makes this functionality buggy. Although the client (maven, IDE, etc.) thinks, that the total number of invoked test is correct, it is not. When we take a look into server's log, we can see that for each single test case it invoked full set of all test cases. It means, that in the end the amount of performed tests is equal to expected count squared. Such behaviour is not only slow but also in some cases it doesn't work and it makes tests to fail. > h2. Example > {code:java} > @DataProvider > public Object[][] sumProvider() { > return new Object[][]{ > new Object[]{ 0, 0, 0 }, > new Object[]{ 1, 1, 2 }, > new Object[]{ 1, 5, 6 }, > new Object[]{ 5, 1, 6 } > }; > } > {code} > h3. Expected output in server log > {quote} > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > {quote} > h3. Actual output > {quote} > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > Execution of sum: 0 + 0 = 0 > Execution of sum: 1 + 1 = 2 > Execution of sum: 1 + 5 = 6 > Execution of sum: 5 + 1 = 6 > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ARQ-808) Apply the formatter for the GlassFish container adapters

by Bartosz Majsak (JIRA)

[ https://issues.jboss.org/browse/ARQ-808?page=com.atlassian.jira.plugin.sy... ] Bartosz Majsak resolved ARQ-808. -------------------------------- Resolution: Done Pushed upstream [@bbeb0a89|https://github.com/arquillian/arquillian-container-glassfish/commit/bbeb0a89a4af3b7d8a1b15530090b3566dcaff44]. > Apply the formatter for the GlassFish container adapters > -------------------------------------------------------- > > Key: ARQ-808 > URL: https://issues.jboss.org/browse/ARQ-808 > Project: Arquillian > Issue Type: Task > Components: GlassFish Containers > Reporter: Vineet Reynolds > Assignee: Bartosz Majsak > Priority: Minor > Fix For: glassfish_1.0.0.Final > > > The formatting in the classes of the GlassFish adapters vary from class to class, and sometimes even across lines. We'll need to use a consistent code formatting scheme for this Maven project. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues April 2016