[JBoss JIRA] (ARQ-700) Properties in arqullian.xml should handle new lines
by Hardy Ferentschik (Created) (JIRA)
Properties in arqullian.xml should handle new lines
----------------------------------------------------
Key: ARQ-700
URL: https://issues.jboss.org/browse/ARQ-700
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 1.0.0.CR6
Reporter: Hardy Ferentschik
When trying to add _javaVmArguments_ to _arquillian.xml_ in order to debug the container new lines in the property will cause the container start to fail.
For example, the following works:
{code}
<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<engine>
<property name="deploymentExportPath">target/</property>
</engine>
<container qualifier="jboss" default="true">
<protocol type="jmx-as7">
<property name="executionType">REMOTE</property>
</protocol>
<configuration>
<property name="jbossHome">target/jboss-as-7.1.0.Beta1</property>
<property name="javaVmArguments">-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m</property>
</configuration>
</container>
</arquillian>
{code}
whereas this fails:
{code}
<arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian
http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<engine>
<property name="deploymentExportPath">target/</property>
</engine>
<container qualifier="jboss" default="true">
<protocol type="jmx-as7">
<property name="executionType">REMOTE</property>
</protocol>
<configuration>
<property name="jbossHome">target/jboss-as-7.1.0.Beta1</property>
<property name="javaVmArguments">
-Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y -Xmx512m -XX:MaxPermSize=128m
</property>
</configuration>
</container>
</arquillian>
{code}
given that often people use auto-formatting for xml the parser should take care of this and trim the configuration value. Also the resulting exception for the case where the value is on a new line is very confusing:
{noformat}
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:180)
at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:78)
at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:198)
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)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
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:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
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.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:71)
at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:199)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [30] s
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:176)
... 65 more
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (ARQ-442) Change Examples modules to a container sanity test suite
by Aslak Knutsen (JIRA)
Change Examples modules to a container sanity test suite
--------------------------------------------------------
Key: ARQ-442
URL: https://issues.jboss.org/browse/ARQ-442
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0.Beta1
Reporter: Aslak Knutsen
The current examples modules should be recreated as a sanity test suite for the containers. Currently all containers have their own simple tests for validating the functionality. These container tests should be merged with the examples and created as a test suite.
The test suite needs to be split up by package / module based on EE v / technology to support all containers(easy maven filtering). The containers should depend on this test suite and not the other way around.
todo: research how to include a external module as a test suite for a module. (copy-dependencies / extract ? / container config etc)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (ARQ-540) Support @ArquillianResource URL for in-container test cases
by Ian Brandt (JIRA)
Support @ArquillianResource URL for in-container test cases
-----------------------------------------------------------
Key: ARQ-540
URL: https://issues.jboss.org/browse/ARQ-540
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0.CR2
Reporter: Ian Brandt
>From [IRC|http://echelog.matzon.dk/logs/browse/jbosstesting/1312408800]:
{quote}
[2:13pm] ianbrandt: aslak, Should @ArquillianResource injection work for in-container test cases? It works fine when I try it for an as-client test, but when I do the same in-container the org.jboss.arquillian.container.test.impl.enricher.resource.URLResourceProvider.protocolMetadata.get() is null, so no context URL. I verified the container is returning a non-null ProtocolMetaData from deploy(...).
[2:15pm] aslak: ianbrandt, no it currently doesn't work
[2:16pm] aslak: ianbrandt, it probably should, but i'm not sure we have the info incontianer without doing a callback to the client..
[2:16pm] aslak: ianbrandt, but then we don't know which deployment we are when incontianer, so we have a little problem there..
[2:17pm] ianbrandt: aslak, Ah, okay.
[2:17pm] aslak: no wait we do
[2:18pm] aslak: the Protocol is executed within a DeploymentScope/ContainerScope, so when it gets the callback, it has the correct context..
[2:18pm] aslak: we tho need OperatesOnDeployment support for that tho, cuz you possible want to inject URLs not to your self, but to another deployment on possible another contianer that you should invoke from incontainer
[2:19pm] aslak: so from incontianer on dep 1, we can do @ArqRes @OperatesOnDep("dep2") URL url;
[2:23pm] ianbrandt: aslak, Makes sense. It's a little more than I could take on at the moment. I was just augmenting the Tomcat tests to show @ArqRes usage. I'll skip it for shouldBeAbleToInvokeServletInDeployedWebApp, and JIRA+Wiki the limitation.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ARQ-647) Implement a convenient way to pass system properties to managed container's JVM.
by Ondrej Zizka (Created) (JIRA)
Implement a convenient way to pass system properties to managed container's JVM.
--------------------------------------------------------------------------------
Key: ARQ-647
URL: https://issues.jboss.org/browse/ARQ-647
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 1.0.0.CR5
Reporter: Ondrej Zizka
Assignee: Aslak Knutsen
Priority: Critical
Currently, the only way to pass system props to a container (say, JBoss AS 7), is to use
{code}
<property name="javaVmArguments">-Dfoo=bar</property>
{code}
It would be great if system properties could be specified in a special way, like:
* by loading a .properties file and setting them in JVM
* from a deployment
* from a path
* from an URL
* by a special config elements
* by taking them all from the launching JVM; possibly only those with a given prefix
Here's how I'd imagine it. Params in [] are optional, with default values.
{code}
<arquillian xmlns="http://jboss.org/schema/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<container qualifier="jboss" default="true">
<configuration>
<property name="jbossHome">target/smoke</property>
<property name="javaVmArguments">${server.jvm.args}</property>
<property name="serverConfig">${server.config:standalone.xml}</property>
<property name="allowConnectingToRunningServer">true</property>
<systemProperties>
<copyCurrent [prefix="arq."]/>
<loadFromDeployment [path="META-INF/arq.system.properties"] [optional="false"]>
<loadFromFile [path="../testsuite/my.properties"] [optional="false"]>
<loadFromUrl [url="http://foo.redhat.com/foo.properties"] [optional="true"]>
<property name="jbossas.ts.integ.dir">${fooBar}</property>
</systemProperties>
</configuration>
</container>
</arquillian>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ARQ-634) Servlet 2.5 support on Servlet 3.0 containers
by Aslak Knutsen (Created) (JIRA)
Servlet 2.5 support on Servlet 3.0 containers
---------------------------------------------
Key: ARQ-634
URL: https://issues.jboss.org/browse/ARQ-634
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Test Protocol SPIs and Implementation
Affects Versions: 1.0.0.CR5
Reporter: Aslak Knutsen
In a Servlet Container that is defined to use the Servlet 3.0 protocol, but the user defined deployment use a web.xml set to 2.5, the Arquillian Servlet which is added as a web-fragment.xml in the Servlet 3.0 impl will be ignored and Arquillian can not find itself.
The Servlet Protocol could possible check the web.xml defined in @Deployment to determine which Servlet Protocol version to use. Meaning the Servlet 3.0 impl can downgrade to Servlet 2.5 in the packaging process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months