[JBoss JIRA] (ARQ-618) ValidationException "DeploymentScenario contains targets not matching any defined Container in the registry." could be even more clear
by Geoffrey De Smet (Created) (JIRA)
ValidationException "DeploymentScenario contains targets not matching any defined Container in the registry." could be even more clear
--------------------------------------------------------------------------------------------------------------------------------------
Key: ARQ-618
URL: https://issues.jboss.org/browse/ARQ-618
Project: Arquillian
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Geoffrey De Smet
Priority: Minor
I deployed to jetty 6 embedded and configured a container qualifier called "jetty-embedded".
Instead of seeing this error message:
{code}
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)
{code}
I would like to see these error messages instead:
if ContainerRegistry.getContainers() == 0 then
{code}
ValidationException: DeploymentScenario contains a target (_DEFAULT_) not matching any defined Container in the registry.
Please include at least 1 Deployable Container in your Classpath.
{code}
otherwise
{code}
ValidationException: DeploymentScenario contains a target (_DEFAULT_) not matching any defined Container in the registry.
Possible causes are: None of the 2 Deployable Containers on your Classpath match or you have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer of value (_DEFAULT_) that does not match any found/configured Containers (jboss-embedded, jetty-embedded), see arquillian.xml container@qualifier.
{code}
Every "()" part contains the runtime values.
Here's the full original exception:
{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}
--
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, 9 months
[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, 9 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, 9 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, 9 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, 9 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, 10 months
[JBoss JIRA] (ARQ-643) Arquillian fails to execute in-container tests when the serverHttps property is enabled for Glassfish containers
by Vineet Reynolds (Created) (JIRA)
Arquillian fails to execute in-container tests when the serverHttps property is enabled for Glassfish containers
----------------------------------------------------------------------------------------------------------------
Key: ARQ-643
URL: https://issues.jboss.org/browse/ARQ-643
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: GlassFish Containers
Reporter: Vineet Reynolds
When the {{serverHttps}} property is enabled in arquillian.xml, execution of in-container tests fail. The failure occurs at the point when the Arquillian client attempts to communicate with the Arquillian Test Runner Servlet. The {{serverHttps}} property is meant to allow for the client to communicate with the server (and the deployed test runner) over SSL, but since the test client ({{ServletUtil}}) constructs a URI with the "http" scheme and not "https", communication with the test runner fails.
We'll need to
* either remote this property for now, and bring this back in a future release when the test client can support communication with the Servlet test runner over SSL,
* or bring in support in Arquillian Core to support communication with the Servlet test runner over SSL.
--
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, 10 months