[JBoss JIRA] (ARQ-619) If multiple DeployableContainers are in the classpath the exception message should clearly say that
by Geoffrey De Smet (Created) (JIRA)
If multiple DeployableContainers are in the classpath the exception message should clearly say that
---------------------------------------------------------------------------------------------------
Key: ARQ-619
URL: https://issues.jboss.org/browse/ARQ-619
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Affects Versions: 1.0.0.CR5
Reporter: Geoffrey De Smet
I 've configured both arquillian-jetty-embedded-6.1 and jboss-as-arquillian-container-managed in my pom.xml.
As a result of some weird exception based code in arquillian, I get this stacktrace which tells me it's another problem (which it is not):
{code}
org.jboss.arquillian.container.test.impl.client.deployment.ValidationException: DeploymentScenario contains targets not matching any defined Container in the registry. _DEFAULT_. Possible causes are: No Deployable Container found on Classpath or your have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer value that does not match any found/configured Containers (see arquillian.xml container@qualifier)
at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.validate(DeploymentGenerator.java:102)
at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:84)
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:96)
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.createClassContext(TestContextHandler.java:68)
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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54)
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.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123)
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)
{code}
So, what happened?
The method org.jboss.arquillian.core.impl.loadable.ServiceRegistryLoader#onlyOne
throw an exception:
{code}
public <T> T onlyOne(Class<T> serviceClass)
{
Collection<T> all = all(serviceClass);
if(all.size() == 1)
{
return all.iterator().next();
}
if(all.size() > 1)
{
throw new IllegalStateException("Multiple service implementations found for " + serviceClass + ". " + toClassString(all)); // <================ GOOD
}
return null;
}
{code}
and the method org.jboss.arquillian.container.impl.client.container.ContainerRegistryCreator#createRegistry
swept it under the covers:
{code} public void createRegistry(@Observes ArquillianDescriptor event)
{
...
if(activeConfiguration == null && reg.getContainers().size() == 0)
{
try
{
DeployableContainer<?> deployableContainer = serviceLoader.onlyOne(DeployableContainer.class);
if(deployableContainer != null)
{
reg.create(new ContainerDefImpl("arquillian.xml").setContainerName("default"), serviceLoader);
}
}
catch (Exception e)
{
// ignore // <====================================================== BAD
}
}
// export
registry.set(reg);
}
{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, 2 months
[JBoss JIRA] Created: (ARQ-473) DeployableContainer should not be restricted to only deploy Descriptors or Archives
by Aslak Knutsen (JIRA)
DeployableContainer should not be restricted to only deploy Descriptors or Archives
-----------------------------------------------------------------------------------
Key: ARQ-473
URL: https://issues.jboss.org/browse/ARQ-473
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Base Implementation, Deployable Containers SPI
Affects Versions: 1.0.0.CR1
Reporter: Aslak Knutsen
Fix For: 1.1.0.CR1
To open up for more specialized Containers we should support some type of 'WildCard' Deploy.
Possible by having a Annotation driven DeployableContainer, e.g.
@Deploy
public SomethingExposedInContext(SomeRandomOtherType type)
This will let us e.g. deploy Files/ Images etc directly for non Java/EE type Containers.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (ARQ-417) Support maven deployments
by Adrian Cole (JIRA)
Support maven deployments
-------------------------
Key: ARQ-417
URL: https://issues.jboss.org/browse/ARQ-417
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Configuration
Reporter: Adrian Cole
Microdeployments via ShrinkWrap are a nimble deployment mechanism that allows developers to test bytecode skipping the build. Another usecase is to have ARQ in a CI loop, testing artifacts post-deploy. For this sort of scenario, it would be useful to reuse test cases from the microdeployments, but have them leveraged against code pulled from maven artifacts published in a prior step.
For example, we could have an @Maven annotation which could define the coordinates of an ear file, and place that on a test scenario that performs the war, ejb, cdi, etc tests of from the dependent modules.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (ARQ-600) Improve Tomcat codebase - Managed
by Aslak Knutsen (JIRA)
Improve Tomcat codebase - Managed
---------------------------------
Key: ARQ-600
URL: https://issues.jboss.org/browse/ARQ-600
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Tomcat Containers
Reporter: Aslak Knutsen
Assignee: Karel Piwko
Fix For: tomcat_1.0.0.Final
After the Tomcat Container code clean up, tomcat-common, it seems all the Managed Tomcat containers are identical both in impl and configuration.
We can create a similar tomcat-common-managed that will have the common parts between the different versions.
{note}
If Tomcat Managed 5.5, 6 and 7 are identical, why do we have 3 versions?
{note}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] Created: (ARQ-480) Create a Notification SPI
by Aslak Knutsen (JIRA)
Create a Notification SPI
-------------------------
Key: ARQ-480
URL: https://issues.jboss.org/browse/ARQ-480
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Base Implementation, Runtime Enricher SPI
Affects Versions: 1.0.0.Final
Reporter: Aslak Knutsen
Fix For: 1.1.0.Beta1
There should be a way for SPI impls to communicate with executor about what they have done outside of throwing exception.
e.g. TestEnrcihers
* EJBEnricher ran first and couldn't find a specific @EJB, but CDI runs after and can.
** EJBEnricher should not fail on his attempt, but should report what he tried and where he failed
** CDI Enricher should be executed regardless of EJBEnrichers outcome
** Summarize in the end to compare if we have a full Enriched Object
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (ARQ-624) Initialization of the extension for remote Glassfish fails when the remote domain configuration does not match the expected configuration
by Vineet Reynolds (Created) (JIRA)
Initialization of the extension for remote Glassfish fails when the remote domain configuration does not match the expected configuration
-----------------------------------------------------------------------------------------------------------------------------------------
Key: ARQ-624
URL: https://issues.jboss.org/browse/ARQ-624
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: GlassFish Containers
Reporter: Vineet Reynolds
Assignee: Vineet Reynolds
Priority: Minor
As explained in the title, the initialization of Arquillian fails on remote Glassfish when the domain configuration is not as expected by Arquillian. The following exception was reported when running the unit tests of glassfish-remote-3.1 against a custom configured domain:
{noformat}
-------------------------------------------------------------------------------
Test set: org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployWarTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 221.294 sec <<< FAILURE!
org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployWarTest Time elapsed: 0 sec <<< ERROR!
java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:417)
at java.lang.Integer.parseInt(Integer.java:499)
at org.jboss.arquillian.container.glassfish.remote_3_1.clientutils.GlassFishClientService.getAdminServerHttpPort(GlassFishClientService.java:408)
at org.jboss.arquillian.container.glassfish.remote_3_1.clientutils.GlassFishClientService$AdminServer.getNodeAddressList(GlassFishClientService.java:549)
at org.jboss.arquillian.container.glassfish.remote_3_1.clientutils.GlassFishClientService.startUp(GlassFishClientService.java:136)
at org.jboss.arquillian.container.glassfish.remote_3_1.GlassFishRestDeployableContainer.start(GlassFishRestDeployableContainer.java:81)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$5.perform(ContainerLifecycleController.java:144)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$5.perform(ContainerLifecycleController.java:134)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:182)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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 java.lang.reflect.Method.invoke(Method.java:597)
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:83)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:76)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachContainer(ContainerLifecycleController.java:175)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainers(ContainerLifecycleController.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
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:76)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:115)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:102)
at org.apache.maven.surefire.Surefire.run(Surefire.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
{noformat}
The following listeners were configured in the Glassfish domain.xml file:
{code:xml}
...
<http-service>
<access-log></access-log>
<virtual-server id="server" network-listeners="http-listener,https-listener"></virtual-server>
<virtual-server id="__asadmin" network-listeners="admin-listener"></virtual-server>
</http-service>
...
{code}
The test succeeded when the name of the listeners were modified from "http-listener-1" and "http-listener-2" to "http-listener" and "https-listener" in GlassFishClientService.getAdminServerHttpPort(...). But this is not desirable, although the names of http-listener-1,http-listener-2 etc. could be useful defaults.
The same might also be true of the DAS (Default Admin Server) name used by the extension (currently set to "server"). The [Domain File Format reference for the server element in domain.xml|http://download.oracle.com/docs/cd/E19226-01/820-7694/abhep/in...] states that
{quote}
The admin-service subelement of the config element referenced by a server's config-ref attribute determines whether the server is the DAS.
{quote}
which might be true of the REST API as well.
Arquillian must either:
1. query Glassfish for the names of the resources before issuing requests using the REST AOU, and choose values from the responses, or
2. must allow these values to be specified in arquillian.xml.
--
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, 3 months
[JBoss JIRA] Created: (ARQ-569) Archive for remote GF-3.1 should not be saved to disk prior to deployment
by Pedro Kowalski (JIRA)
Archive for remote GF-3.1 should not be saved to disk prior to deployment
-------------------------------------------------------------------------
Key: ARQ-569
URL: https://issues.jboss.org/browse/ARQ-569
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: GlassFish Containers
Affects Versions: glassfish_1.0.0.CR1
Environment: Ubuntu 11.04 x86, GlassFish Server Open Source Edition 3.1.1 (build 12)
Reporter: Pedro Kowalski
When I build the deployment archive, it is saved it /tmp/ARCHIVE_FILENAME (I'm running on GNU/Linux box) with chmod 444 (-r--r--r--). If I run the glassfish server as a root or as the same user as the maven than there is no problem. But actually I run a Jenkins build task (user: jenkins) and run the server as another user (user: pedro).
In such case, the Arquillian remote tests fail because the Glassfish cannot use the /tmp/ARCHIVE_FILENAME (permission denied). If you change the chmod and give others the write permission - it will work fine.
Aslak suggested avoiding the FileDataBodyPart during deployment.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months