[JBoss JIRA] (ARQ-856) Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
by sarah333 Aldhen (JIRA)
[ https://issues.jboss.org/browse/ARQ-856?page=com.atlassian.jira.plugin.sy... ]
sarah333 Aldhen commented on ARQ-856:
-------------------------------------
Yes i'm using maven. I'm sorry but which dependency are you talking about ? here are my dependencies :
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-glassfish-embedded-3.1</artifactId>
<version>1.0.0.CR2</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.glassfish.main.extras</groupId>
<artifactId>glassfish-embedded-all</artifactId>
<version>3.1.2</version>
<scope>provided</scope>
</dependency>
> Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
> -------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-856
> URL: https://issues.jboss.org/browse/ARQ-856
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Fix For: glassfish_1.0.0.CR4
>
>
> The embedded GlassFish container uses the default HTTP bind port of 8181, even though the user-supplied domain configuration XML file may specify a different HTTP port. This results in the following exception being thrown when the Arquillian client attempts to execute a test:
> {code}
> ...
> INFO: WELD-000900 SNAPSHOT
> 9 Apr, 2012 11:06:12 AM com.sun.enterprise.web.WebApplication start
> INFO: WEB0671: Loading application [test] at [/test]
> 9 Apr, 2012 11:06:13 AM org.glassfish.deployment.admin.DeployCommand execute
> INFO: test was successfully deployed in 18,014 milliseconds.
> java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:206)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.access$000(ServletMethodExecutor.java:43)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor$1.run(ServletMethodExecutor.java:99)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {code}
> Note that the deployment is successful, but the {{HTTPContext}} returned by the embedded GlassFish adapter contains the wrong port information. In this case, the http-listener-1/http-listener-2 combo was registered in domain.xml to listen on 8080/8181. When Arquillian established a connection to port 8181, the container obviously did not respond to plain text HTTP traffic, and quite obviously the client errored out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-856) Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/ARQ-856?page=com.atlassian.jira.plugin.sy... ]
Vineet Reynolds commented on ARQ-856:
-------------------------------------
[~sarah333] this should have been fixed in version 1.0.0.CR4 of the GlassFish adapter. Please ensure that you are using that specific version of the adapter as a test dependency in your project. If you are using Maven, {{mvn dependency:tree}} will aid you in determining if you have the right set of dependencies.
> Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
> -------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-856
> URL: https://issues.jboss.org/browse/ARQ-856
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Fix For: glassfish_1.0.0.CR4
>
>
> The embedded GlassFish container uses the default HTTP bind port of 8181, even though the user-supplied domain configuration XML file may specify a different HTTP port. This results in the following exception being thrown when the Arquillian client attempts to execute a test:
> {code}
> ...
> INFO: WELD-000900 SNAPSHOT
> 9 Apr, 2012 11:06:12 AM com.sun.enterprise.web.WebApplication start
> INFO: WEB0671: Loading application [test] at [/test]
> 9 Apr, 2012 11:06:13 AM org.glassfish.deployment.admin.DeployCommand execute
> INFO: test was successfully deployed in 18,014 milliseconds.
> java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:206)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.access$000(ServletMethodExecutor.java:43)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor$1.run(ServletMethodExecutor.java:99)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {code}
> Note that the deployment is successful, but the {{HTTPContext}} returned by the embedded GlassFish adapter contains the wrong port information. In this case, the http-listener-1/http-listener-2 combo was registered in domain.xml to listen on 8080/8181. When Arquillian established a connection to port 8181, the container obviously did not respond to plain text HTTP traffic, and quite obviously the client errored out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-856) Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
by sarah333 Aldhen (JIRA)
[ https://issues.jboss.org/browse/ARQ-856?page=com.atlassian.jira.plugin.sy... ]
sarah333 Aldhen commented on ARQ-856:
-------------------------------------
I have this problem. What should i do to resolve it ?? i tried to replace the port 8181 with 8686 but i still have the same error .
> Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
> -------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-856
> URL: https://issues.jboss.org/browse/ARQ-856
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Fix For: glassfish_1.0.0.CR4
>
>
> The embedded GlassFish container uses the default HTTP bind port of 8181, even though the user-supplied domain configuration XML file may specify a different HTTP port. This results in the following exception being thrown when the Arquillian client attempts to execute a test:
> {code}
> ...
> INFO: WELD-000900 SNAPSHOT
> 9 Apr, 2012 11:06:12 AM com.sun.enterprise.web.WebApplication start
> INFO: WEB0671: Loading application [test] at [/test]
> 9 Apr, 2012 11:06:13 AM org.glassfish.deployment.admin.DeployCommand execute
> INFO: test was successfully deployed in 18,014 milliseconds.
> java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:206)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.access$000(ServletMethodExecutor.java:43)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor$1.run(ServletMethodExecutor.java:99)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {code}
> Note that the deployment is successful, but the {{HTTPContext}} returned by the embedded GlassFish adapter contains the wrong port information. In this case, the http-listener-1/http-listener-2 combo was registered in domain.xml to listen on 8080/8181. When Arquillian established a connection to port 8181, the container obviously did not respond to plain text HTTP traffic, and quite obviously the client errored out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQGRA-313) Allow to inject unique page fragment from page without specifying root locator
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-313?page=com.atlassian.jira.plugin... ]
Lukáš Fryč commented on ARQGRA-313:
-----------------------------------
Rather than @AutoFindBy, it might be clever to use:
{code}
@AutoFindable(@FindBy(css = ".rf-cal"))
{code}
{code}
@AutoFindable @FindBy(css = ".rf-cal"))
{code}
We must make sure to throw an exception when more than one occurence will be found.
> Allow to inject unique page fragment from page without specifying root locator
> ------------------------------------------------------------------------------
>
> Key: ARQGRA-313
> URL: https://issues.jboss.org/browse/ARQGRA-313
> Project: Arquillian Graphene
> Issue Type: Feature Request
> Reporter: Lukáš Fryč
>
> The page fragment can contain instructions how to find itself in the given context:
> {code:java}
> @AutoFindBy(".rf-cal")
> public class Calendar {
> }
> {code}
> One can then inject such a page fragment without specifying locator:
> {code:java}
> @FindBy
> Calendar calendar;
> {code}
> Note that the context of searching is dependent upon an injection point (where is page fragment being injected).
> E.g.:
> * whole page
> * page fragment
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQGRA-313) Allow to inject unique page fragment from page without specifying root locator
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/ARQGRA-313?page=com.atlassian.jira.plugin... ]
Juraj Húska commented on ARQGRA-313:
------------------------------------
IMHO it is an useful addition. I will start to work on it once it is scheduled.
> Allow to inject unique page fragment from page without specifying root locator
> ------------------------------------------------------------------------------
>
> Key: ARQGRA-313
> URL: https://issues.jboss.org/browse/ARQGRA-313
> Project: Arquillian Graphene
> Issue Type: Feature Request
> Reporter: Lukáš Fryč
>
> The page fragment can contain instructions how to find itself in the given context:
> {code:java}
> @AutoFindBy(".rf-cal")
> public class Calendar {
> }
> {code}
> One can then inject such a page fragment without specifying locator:
> {code:java}
> @FindBy
> Calendar calendar;
> {code}
> Note that the context of searching is dependent upon an injection point (where is page fragment being injected).
> E.g.:
> * whole page
> * page fragment
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-567) Supporting Test Suites (@ArquillianSuite)
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-567?page=com.atlassian.jira.plugin.sy... ]
Aslak Knutsen commented on ARQ-567:
-----------------------------------
[~peter.probst] This is why the Suite Extension is not official yet. The internal SPIs for handling multiple Classes in a Suite etc are not present, so some extensions (specially those that rely on providing TestClass specific configuration to the Deployment) does not work.
> Supporting Test Suites (@ArquillianSuite)
> -----------------------------------------
>
> Key: ARQ-567
> URL: https://issues.jboss.org/browse/ARQ-567
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Mousavi Jahan Abadi S. M.
>
> Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like:
> @RunWith(ArquillianSuite.class)
> @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } )
> public class AllTests{
> @Deployment
> public static JavaArchive createTestArchive(){
> return ShrinkWrap.create(JavaArchive.class,"test.jar");
> }
> }
> The advantages of above approach for users of Arquillian framework are:
> - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users).
> - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions.
> The advantage of above approach for framework itself is:
> - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-567) Supporting Test Suites (@ArquillianSuite)
by Peter Probst (JIRA)
[ https://issues.jboss.org/browse/ARQ-567?page=com.atlassian.jira.plugin.sy... ]
Peter Probst commented on ARQ-567:
----------------------------------
Hello Bernard,
thank you for pinpointing the suite extension and your and aslaks work on that. I've tested extension and the suite alone is working properly, but we are using persistence extension (1.0.0.Alpha5) and then following exception occurs:
java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
at org.jboss.arquillian.persistence.core.deployment.PersistenceExtensionArchiveAppender.requiredLibraries(PersistenceExtensionArchiveAppender.java:81)
Unfortunately the real exception is eaten and i can't debug within persistence extension.
Thanks, Peter
> Supporting Test Suites (@ArquillianSuite)
> -----------------------------------------
>
> Key: ARQ-567
> URL: https://issues.jboss.org/browse/ARQ-567
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Mousavi Jahan Abadi S. M.
>
> Currently, it is supported that JUnit test cases being run by Arquillian. This feature request is request for supporting test suites too to be run by Arquillian too. Idea is like:
> @RunWith(ArquillianSuite.class)
> @Suite.SuiteClasses( { TestCase1.class, TestCase2.class, .... } )
> public class AllTests{
> @Deployment
> public static JavaArchive createTestArchive(){
> return ShrinkWrap.create(JavaArchive.class,"test.jar");
> }
> }
> The advantages of above approach for users of Arquillian framework are:
> - Test cases don't needed to be modified to have: "@RunWith(Arquillian.class)" annotation. In other words, test cases will be pure JUnit code, and no Arquillian code (results in less coding for end users).
> - It is not necessary to include the static "@Deployment" methods in all test cases any more, and only Test Suite need to define the archieving/deployment related setting/definitions.
> The advantage of above approach for framework itself is:
> - From performance point-of-view, it becomes possible for Arquillian to deploy all test cases in the Test Suite into J2EE container in one action (one deploy/undeploy for one test suite, instead of mulitple deploy/undeploy for each test case).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-1428) Screen Recorder with TestNG standalone causes java.lang.NoClassDefFoundError
by Petr Mensik (JIRA)
[ https://issues.jboss.org/browse/ARQ-1428?page=com.atlassian.jira.plugin.s... ]
Petr Mensik commented on ARQ-1428:
----------------------------------
This issued is caused by setting root directory to the target - this deletes all compiled classes during runtime.
> Screen Recorder with TestNG standalone causes java.lang.NoClassDefFoundError
> ----------------------------------------------------------------------------
>
> Key: ARQ-1428
> URL: https://issues.jboss.org/browse/ARQ-1428
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Alpha2
> Environment: Fedora 18, Firefox 22
> Reporter: Petr Mensik
> Attachments: project.tar
>
>
> Running functional test with Drone, Graphene, Screen Recorder in TestNG standalone mode with cause java.lang.NoClassDefFoundError after start of the embedded Jetty server. Problem is caused by the injection of page object to the test case, so for instance @Page SimplePage page;.
> {noformat} java.lang.NoClassDefFoundError: Lorg/arquillian/screenRecorder/bug/page/SimplePage;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2387)
> at java.lang.Class.getDeclaredFields(Class.java:1796)
> at org.jboss.arquillian.drone.impl.SecurityActions$2.run(SecurityActions.java:163)
> at org.jboss.arquillian.drone.impl.SecurityActions$2.run(SecurityActions.java:158)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.arquillian.drone.impl.SecurityActions.getFieldsWithAnnotation(SecurityActions.java:158)
> at org.jboss.arquillian.drone.impl.DroneConfigurator.configureDrone(DroneConfigurator.java:102)
> 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.testng.Arquillian.arquillianBeforeClass(Arquillian.java:103)
> Caused by: java.lang.ClassNotFoundException: org.arquillian.screenRecorder.bug.page.SimplePage
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357){noformat}
> Also note that it works correctly with standalone JUnit (just added dependency to JUnit, junit-standalone and changed annotations in test class)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-1428) Screen Recorder with TestNG standalone causes java.lang.NoClassDefFoundError
by Petr Mensik (JIRA)
[ https://issues.jboss.org/browse/ARQ-1428?page=com.atlassian.jira.plugin.s... ]
Petr Mensik resolved ARQ-1428.
------------------------------
Resolution: Rejected
> Screen Recorder with TestNG standalone causes java.lang.NoClassDefFoundError
> ----------------------------------------------------------------------------
>
> Key: ARQ-1428
> URL: https://issues.jboss.org/browse/ARQ-1428
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.0.0.Alpha2
> Environment: Fedora 18, Firefox 22
> Reporter: Petr Mensik
> Attachments: project.tar
>
>
> Running functional test with Drone, Graphene, Screen Recorder in TestNG standalone mode with cause java.lang.NoClassDefFoundError after start of the embedded Jetty server. Problem is caused by the injection of page object to the test case, so for instance @Page SimplePage page;.
> {noformat} java.lang.NoClassDefFoundError: Lorg/arquillian/screenRecorder/bug/page/SimplePage;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2387)
> at java.lang.Class.getDeclaredFields(Class.java:1796)
> at org.jboss.arquillian.drone.impl.SecurityActions$2.run(SecurityActions.java:163)
> at org.jboss.arquillian.drone.impl.SecurityActions$2.run(SecurityActions.java:158)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.arquillian.drone.impl.SecurityActions.getFieldsWithAnnotation(SecurityActions.java:158)
> at org.jboss.arquillian.drone.impl.DroneConfigurator.configureDrone(DroneConfigurator.java:102)
> 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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.testng.Arquillian.arquillianBeforeClass(Arquillian.java:103)
> Caused by: java.lang.ClassNotFoundException: org.arquillian.screenRecorder.bug.page.SimplePage
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357){noformat}
> Also note that it works correctly with standalone JUnit (just added dependency to JUnit, junit-standalone and changed annotations in test class)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (ARQ-1429) Spock Appender is missing org.objectweb.asm package
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1429?page=com.atlassian.jira.plugin.s... ]
Karel Piwko commented on ARQ-1429:
----------------------------------
Upstream fix for ASM accepted. http://forge.ow2.org/tracker/?func=detail&atid=100023&aid=316482&group_id=23
> Spock Appender is missing org.objectweb.asm package
> ---------------------------------------------------
>
> Key: ARQ-1429
> URL: https://issues.jboss.org/browse/ARQ-1429
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Spock TestRunner
> Affects Versions: spock_1.0.0.Beta1
> Reporter: Karel Piwko
> Assignee: Karel Piwko
> Priority: Blocker
>
> ASM is used in Groovy, which leads to CNFE when run in server.
> {code}
> @Produces
> @PersistenceContext(unitName = "pushee-default", type = PersistenceContextType.EXTENDED)
> @Default
> EntityManager entityManager;
> @Inject
> PushApplicationDao pushAppDao;
> def "find all registered apps"() {
> when: "Check for all registered apps"
> List<PushApplication> apps = pushAppDao.findAll();
> then: "DAO was injected"
> pushAppDao!=null
> and: "No applications were defined"
> apps.size()==0
> }
> {code}
> leads to:
> {code}
> 17:19:55,691 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /test
> 17:19:55,742 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS018559: Deployed "test.war"
> 17:19:56,485 WARN [org.jboss.modules] (http--127.0.0.1-8080-1) Failed to define class org.codehaus.groovy.ast.FieldNode in Module "deployment.test.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/codehaus/groovy/ast/FieldNode (Module "deployment.test.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:396)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73)
> at org.jboss.modules.Module.loadModuleClass(Module.java:517)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> at java.lang.Class.getDeclaredConstructors0(Native Method) [rt.jar:1.7.0_21]
> at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413) [rt.jar:1.7.0_21]
> at java.lang.Class.getConstructor0(Class.java:2723) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance0(Class.java:345) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_21]
> at org.codehaus.groovy.vmplugin.VMPluginFactory.createPlugin(VMPluginFactory.java:56) [arquillian-spock.jar:]
> at org.codehaus.groovy.vmplugin.VMPluginFactory.<clinit>(VMPluginFactory.java:41) [arquillian-spock.jar:]
> at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:99) [arquillian-spock.jar:]
> at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:71) [arquillian-spock.jar:]
> at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:33) [arquillian-spock.jar:]
> at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:162) [arquillian-spock.jar:]
> at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:192) [arquillian-spock.jar:]
> at org.jboss.aerogear.connectivity.jpa.dao.impl.PushDaoSpecification.$getStaticMetaClass(PushDaoSpecification.groovy) [3728ce10-7709-4805-ac00-a0983db929fd.jar:]
> at org.jboss.aerogear.connectivity.jpa.dao.impl.PushDaoSpecification.<init>(PushDaoSpecification.groovy) [3728ce10-7709-4805-ac00-a0983db929fd.jar:]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance0(Class.java:374) [rt.jar:1.7.0_21]
> at java.lang.Class.newInstance(Class.java:327) [rt.jar:1.7.0_21]
> at org.spockframework.runtime.BaseSpecRunner.createSpecInstance(BaseSpecRunner.java:121) [arquillian-spock.jar:]
> at org.spockframework.runtime.BaseSpecRunner.run(BaseSpecRunner.java:80) [arquillian-spock.jar:]
> at org.spockframework.runtime.Sputnik.run(Sputnik.java:63) [arquillian-spock.jar:]
> at org.jboss.arquillian.spock.container.SpockTestRunner.runTest(SpockTestRunner.java:81) [arquillian-spock.jar:]
> at org.jboss.arquillian.spock.container.SpockTestRunner.execute(SpockTestRunner.java:61) [arquillian-spock.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160) [arquillian-protocol.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126) [arquillian-protocol.jar:]
> at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90) [arquillian-protocol.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.5.AS71.Final.jar:2012-02-10 15:31]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.NoClassDefFoundError: org/objectweb/asm/Opcodes
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_21]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:791) [rt.jar:1.7.0_21]
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) [rt.jar:1.7.0_21]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:327)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:391)
> ... 55 more
> Caused by: java.lang.ClassNotFoundException: org.objectweb.asm.Opcodes from [Module "deployment.test.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
> ... 60 more
> {code}
> The problematic part is that asm suffers the same problem as Groovy pre 2.1.4 version (http://jira.codehaus.org/browse/GROOVY-6158)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months