[JBoss JIRA] (ARQ-913) Allow the log threshold to be configured for managed JBoss AS 6
by Dan Allen (JIRA)
Dan Allen created ARQ-913:
-----------------------------
Summary: Allow the log threshold to be configured for managed JBoss AS 6
Key: ARQ-913
URL: https://issues.jboss.org/browse/ARQ-913
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: JBoss AS Containers
Affects Versions: jbossas_1.0.0.CR3
Reporter: Dan Allen
The managed JBoss AS 6 adapter does not explicitly set the log threshold on the server controller. As a result, the server controller defaults the log threshold to DEBUG. You can see this setting reflected in the start command:
{code}
-Djboss.server.log.threshold=DEBUG
{code}
This threshold produces an enormous amount of log statements, which get redirected to the server/default/log/output.log file.
Here's a comparison of the log file size between various threshold levels:
DEBUG: 2.2 MB
INFO: 80 KB
ERROR: 76 KB
The server starts much faster when the threshold is higher, so we should allow this setting to be configured. If a configuration value is not set, the level should default to INFO (rather than the fallback of DEBUG).
--
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
13 years, 11 months
[JBoss JIRA] Created: (ARQ-585) Support for adding a beans.xml without discarding the original beans.xml with .mergeAsResource()
by Geoffrey De Smet (JIRA)
Support for adding a beans.xml without discarding the original beans.xml with .mergeAsResource()
------------------------------------------------------------------------------------------------
Key: ARQ-585
URL: https://issues.jboss.org/browse/ARQ-585
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Geoffrey De Smet
Priority: Critical
Presume these 2 beans.xml files:
Production code: beans.xml:
{code}
<beans xmlns="http://java.sun.com/xml/ns/javaee" ...>
<!-- 100 lines that change regularly during development -->
</beans>
{code}
Test addition: test-beans.xml:
{code}
<beans xmlns="http://java.sun.com/xml/ns/javaee" ...>
<alternatives>
<class>org.drools.guvnor.server.repository.TestRepositoryStartupService</class>
</alternatives>
</beans>
{code}
Now, for non-test runs (such as in the IDE or in production), only the beans.xml is activated through weld and the test-only alternative should not be activated.
For test runs, the test-only alternative should be activated, yet the rest of the content from beans.xml should be in there too.
So it should be merged to something like this:
{code}
<beans xmlns="http://java.sun.com/xml/ns/javaee" ...>
<!-- 100 lines that change regularly during development -->
<alternatives>
<class>org.drools.guvnor.server.repository.TestRepositoryStartupService</class>
</alternatives>
</beans>
{code}
It would be nice if we do something like mergeAsResource(), shown in this example:
{code}
public static WebArchive createDeployment() {
WebArchive webArchive = ShrinkWrap.create(ExplodedImporter.class, "guvnor-webapp-5.3.0-SNAPSHOT.war")
.importDirectory(new File("target/guvnor-webapp-5.3.0-SNAPSHOT/"))
.as(WebArchive.class)
.mergeAsResource(new File("target/test-classes/META-INF/test-beans.xml"), "META-INF/beans.xml")
.addAsResource(new File("target/test-classes/"), ArchivePaths.create(""))
.addAsLibraries(
DependencyResolvers.use(MavenDependencyResolver.class)
.includeDependenciesFromPom("pom.xml")
.resolveAsFiles(new ScopeFilter("test")));
return webArchive;
}
{code}
Because of maintenance, copying everything from beans.xml to test-beans.xml on every change to beans.xml is NOT an option.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (ARQ-615) Arquillian must scale to a high number of full-layer integration tests
by Geoffrey De Smet (JIRA)
Arquillian must scale to a high number of full-layer integration tests
----------------------------------------------------------------------
Key: ARQ-615
URL: https://issues.jboss.org/browse/ARQ-615
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Geoffrey De Smet
Priority: Critical
A full-layer integration test is an arquillian test which deploys the entire war of a webapp (for example guvnor-webapp) and then runs a higher number of test classes and test methods on it.
Currently arquillian doesn't scale out to that. For different reasons.
The main reason is ARQ-197: every test case starts the container again and after a while tomcat6-managed goes out of memory.
But there are other reasons. This should be tested.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (ARQ-909) Log failure when unable to load extension
by Chris Williams (JIRA)
Chris Williams created ARQ-909:
----------------------------------
Summary: Log failure when unable to load extension
Key: ARQ-909
URL: https://issues.jboss.org/browse/ARQ-909
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Base Implementation
Affects Versions: glassfish_1.0.0.CR3, 1.0.0.Final
Reporter: Chris Williams
Priority: Minor
I'm trying to get the systemproperties extension to work and can't even tell if it's getting picked up from my arquillian.xml file. I changed the name to systempropertiesnoworkie and expected some error but got nothing. It'd be nice to see some sort of logging when an extension is loaded and when an extension can't be found.
--
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
13 years, 11 months
[JBoss JIRA] (ARQ-911) Report better error if ssh key is not registered with OpenShift account
by Dan Allen (JIRA)
Dan Allen created ARQ-911:
-----------------------------
Summary: Report better error if ssh key is not registered with OpenShift account
Key: ARQ-911
URL: https://issues.jboss.org/browse/ARQ-911
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: OpenShift Containers
Affects Versions: openshift_1.0.0.Beta1
Reporter: Dan Allen
Assignee: Karel Piwko
Priority: Critical
The OpenShift container clones the remote git repository configured in arquillian.xml into a temporary directory to exchange files with the test application. The clone is performed over an SSH connection that's negotiated using a public/private RSA key pair. If the public key is not registered with the account, the test fails with the following exception:
{quote}
Exception caught during execution of fetch command
TransportException session is down
{quote}
This sends the developer on a wild goose chase because this error is reported for just about any kind of SSH connection failure.
The problem is revealed if you attempt to ssh into the account:
{quote}
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
{quote}
It would be nice if we could find a way to get this message to be passed through. However, it might be even more useful if we recognize that the connection failure is mostly likely the result of the key not being registered and we can advice the developer
a) how to register it (the client tool command)
b) how to check it
{code}
rhc sshkey add -k ~/.ssh/libra_id_rsa.pub -i libra
ssh -i ~/.ssh/libra_id_rsa 123456789123456789(a)TEST_APP-USER_DOMAIN.rhcloud.com
{code}
The full stack trace of the exception is below:
{code}
org.eclipse.jgit.api.errors.JGitInternalException: Exception caught during execution of fetch command
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:138)
at org.eclipse.jgit.api.CloneCommand.fetch(CloneCommand.java:175)
at org.eclipse.jgit.api.CloneCommand.call(CloneCommand.java:121)
at org.jboss.arquillian.container.openshift.express.OpenShiftRepository.initialize(OpenShiftRepository.java:235)
at org.jboss.arquillian.container.openshift.express.OpenShiftRepository.<init>(OpenShiftRepository.java:75)
at org.jboss.arquillian.container.openshift.express.OpenShiftExpressContainer.start(OpenShiftExpressContainer.java:102)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: org.eclipse.jgit.errors.TransportException: ssh://123456789123456789@TEST_APP-USER_DOMAIN.rhcloud.com/~/git/TEST_APP.git/: session is down
at org.eclipse.jgit.transport.JschSession$JschProcess.<init>(JschSession.java:154)
at org.eclipse.jgit.transport.JschSession$JschProcess.<init>(JschSession.java:118)
at org.eclipse.jgit.transport.JschSession.exec(JschSession.java:91)
at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:248)
at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:147)
at org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:127)
at org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:113)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1062)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:129)
... 72 more
Caused by: com.jcraft.jsch.JSchException: session is down
at com.jcraft.jsch.Session.openChannel(Session.java:762)
at org.eclipse.jgit.transport.JschSession$JschProcess.<init>(JschSession.java:147)
... 80 more
{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
13 years, 11 months
[JBoss JIRA] (ARQ-910) JNDI lookup fails for @EJB mappedName when the bean has more instances
by Josef Cacek (JIRA)
Josef Cacek created ARQ-910:
-------------------------------
Summary: JNDI lookup fails for @EJB mappedName when the bean has more instances
Key: ARQ-910
URL: https://issues.jboss.org/browse/ARQ-910
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Josef Cacek
Priority: Critical
EJBs are not injected correctly to a test case if they come from different applications.
For instance following code:
{code}
@EJB(mappedName = "java:global/test-app1/HelloBean")
private Hello hello1;
@EJB(mappedName = "java:global/test-app2/HelloBean")
private Hello hello2;
@Deployment(name = "DEP1")
public static JavaArchive deploymentApp1() throws IllegalArgumentException, IOException {
return createJar("test-app1.jar");
}
@Deployment(name = "DEP2")
public static JavaArchive deploymentApp2() throws IllegalArgumentException, IOException {
return createJar("test-app2.jar");
}
@Test
@OperateOnDeployment("DEP1")
public void test1() throws Exception {
assertNotNull(hello1);
}
@Test
@OperateOnDeployment("DEP2")
public void test2() throws Exception {
assertNotNull(hello2);
}
{code}
Then one of the tests fails and one passes (sometime test1, sometime test2).
--
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
13 years, 11 months
[JBoss JIRA] (ARQ-908) Support multi container setup
by Aslak Knutsen (JIRA)
Aslak Knutsen created ARQ-908:
---------------------------------
Summary: Support multi container setup
Key: ARQ-908
URL: https://issues.jboss.org/browse/ARQ-908
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Byteman
Affects Versions: byteman_1.0.0.Alpha1
Reporter: Aslak Knutsen
Fix For: byteman_1.0.0.next
We need to support connecting the agent to more then one running jvm. In e.g. a Cluster test setup multiple JVMs on local and remote would be involved. The Byteman extension should be able to figure out the port/ip of the individual containers where the agent is installed.
When running multiple containers on same ip, the extension need to detect the setup and install the agent on different ports.
--
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
13 years, 11 months