JBossDeveloper

Andrew Rubinger wrote:

 

I've started to implement the JBossAS Embedded Container for Arquillian and have a few initial impressions.

 

@Deployment on the test case allows for a user to supply the archive intended for deployment.  Similarly, many backing containers (JBossAS included) have an object metadata model which provides configuration, and it'd be nice to allow the user to supply this.

 

So if I may mock up at a high (ie. user) level:

 

@Configuration
public static ContainerConfiguration getConfig()
{
   return new JBossASContainerConfiguration(  // Arquillian wrapper config class
      JBossASServerConfigFactory.createConfig().bindPort(8080)
         .serverName("all").bindAddress("localhost")
   );
}
 

Then we might have typed configurations per container and give users the native DSL underlying (as I think Pete's getting at).  Mandating a config in schema is IMO unnecessary in some places.

I completely agree that whatever we are configuring in XML should be also possible to configure in Java. At the end of the day, we are just trying to communicate per-server configuration settings. It really doesn't matter where that configuration lives. Some developers will prefer XML, others Java. I would like to centralize the information, though, so that it doesn't have to be on every test class.

I think it's important that each configuration be assigned an id by the developer.

@Configuration("jbossas1")
public static ContainerConfiguration getContainerConfiguration() {
   return new JBossASContainerConfiguration(
     ... 
   );
}

That way, we can introduce commandline switches (or alternative mechanism) to activate the server vendor and configuration that Arquillian will use.

p.s. I'm still hoping for a way to run the same suite against multiple target servers in sequence (i.e., execute mvn test once, tests run against n number of servers)

Dan Allen wrote:

That way, we can introduce commandline switches (or alternative mechanism) to activate the server vendor and configuration that Arquillian will use.

 

p.s. I'm still hoping for a way to run the same suite against multiple target servers in sequence (i.e., execute mvn test once, tests run against n number of servers)

Agreed.  I'm currently relying on a Maven profile-based system where the dependency upon the target container is in the profile.

Another case though: I'd like to activate the server vendor based on the test class.  This means that we wouldn't need to do any other configuration in IDE JUnit/TestNG runners to pass in properties; we could have a base class with all the logic, then subclasses which simply extend the base, and add a single annotation saying "run this one in JBossAS Embedded".  Executing Run As > JUnit on the subclass would then do the right thing.

S,

ALR

German Escobar wrote:

An object metadata model to provide configuration is possible with the design I proposed. We would need to create another builder (i.e. AnnotatedConfigurationBuilder or whatever you want to call it) and establish priorities between the builders (right now we only have XmlConfigurationBuilder).

Super; more builders.

S,

ALR

Andrew Rubinger wrote:

Dan Allen wrote:

That way, we can introduce commandline switches (or alternative mechanism) to activate the server vendor and configuration that Arquillian will use.

 

p.s. I'm still hoping for a way to run the same suite against multiple target servers in sequence (i.e., execute mvn test once, tests run against n number of servers)

Agreed.  I'm currently relying on a Maven profile-based system where the dependency upon the target container is in the profile.

I really hate that approach too, and I can tell you that it demos very poorly. Having to swap Maven profiles in the IDE raises eyebrows because it looks like we are having to do special IDE tweaking to make this work.

Another case though: I'd like to activate the server vendor based on the test class.  This means that we wouldn't need to do any other configuration in IDE JUnit/TestNG runners to pass in properties; we could have a base class with all the logic, then subclasses which simply extend the base, and add a single annotation saying "run this one in JBossAS Embedded".  Executing Run As > JUnit on the subclass would then do the right thing.

Thought provoking. The CDI TCK would differentiate between tests which could only be run on a Java EE application server by annotating them with @IntegrationTest (test classes without this annotation were assumed to be compatible with a standalone CDI environment). The set of possibilities there was closed. We need to offer an open set. So I agree there should be some way to mark the compatibility of a test.

@RunWith(Arquillian.class)
@RunsOn({JBossASContainer.class, GlassFishV3Container.class})
public class MyArquillianTest { ... }

I'm not sure whether @RunsOn should reference configuration ids, built-in names or some class or interface name. We'll cross that bridge when we get to it.

So here's how this would go down. You activate a container (in the future perhaps more than one), and if a test is specified to be compatible with the current container configuration class, or the @RunsOn annotation is absent, the test is executed.

@RunWith(Arquillian.class)
@RunsOn({JBossASContainer.class, GlassFishV3Container.class})
public class MyArquillianTest { ... }

 

I'm not sure whether @RunsOn should reference configuration ids, built-in names or some class or interface name. We'll cross that bridge when we get to it.

 

So here's how this would go down. You activate a container (in the future perhaps more than one), and if a test is specified to be compatible with the current container configuration class, or the @RunsOn annotation is absent, the test is executed.

That would mean you will have to change your test suite to run on a new container?

Aslak Knutsen wrote:

@RunWith(Arquillian.class)
@RunsOn({JBossASContainer.class, GlassFishV3Container.class})
public class MyArquillianTest { ... }

 

I'm not sure whether @RunsOn should reference configuration ids, built-in names or some class or interface name. We'll cross that bridge when we get to it.

 

So here's how this would go down. You activate a container (in the future perhaps more than one), and if a test is specified to be compatible with the current container configuration class, or the @RunsOn annotation is absent, the test is executed.

That would mean you will have to change your test suite to run on a new container?

Yes, this declaration would be intentionally narrowing--though used sparingly. You are marking a test as only targeting only a certain environment.

I would advise having these container classes inherit from a common capabilities class to put back some flexibility. For instance:

@RunsOn(JavaEE6Container.class)

A great example would be a JMS test. You can't run that on a vanilla servlet container, so you have to narrow its compatibility.