I have got AS started up in arquillian using the embedded stuff I've been working on, the test class currently needs these annotations:

@RunWith(Arquillian.class)

@Run(AS_CLIENT)

@ModuleTestSetup(

        testModule=@ModuleDef(

                name="test.module",

                packages={@PackageResource(directory="target/classes", packages={"org.jboss.arquillian.container.jboss.embedded_7"}),

                        @PackageResource(directory="target/test-classes", packages={"org.jboss.arquillian.container.test.jboss.embedded_7"})},

                dependencies= {@Dependency("javax.servlet.api")}),

        tcclModule=@ModuleDef (

                name="test.demos.tccl",

                dependencies= {@Dependency("org.jboss.logging"), @Dependency("org.jboss.logmanager")})

)

@ClassFactory(JBossEmbeddedClassFactoryProvider.class)

public class JBossEmbeddedContainerTestCase

The @ClassFactory annotation is a signal to the Arquillian which now does this

   public Arquillian(Class<?> klass) throws InitializationError

   {

      super(getTestClass(klass));

      try

      {

         // first time we're being initialized

         if(deployableTest.get() == null)

         ....

   }

The default behaviour of getTestClass() is to just return the original class. If @ClassFactory is there, it uses JBossEmbeddedClassFactoryProvider to set up the modules from @ModuleTestSetup, and then loads up the test class loaded from modules returns that. I need this hook, but how it is set up now was just a quick hack, so Aslak if you have any preferences on how to configure this please let me know.

I got around the java.util.logging.Logging issues by setting the tcclModule's classloader as the thread context classloader in JBossEmbeddedClassFactoryProvider.getTestClass() so it gets initialized properly.

I have not deployed anything yet but will look at that tomorrow along with tidying up the module setup, which I think when running in this framework is a bit too verbose at the moment. I am hoping that we can just define the dependencies for the test deployments and then to be able to generate each deployment's manifest.mf from the annotations.

I've taken a better look at your solution now, and we are taking two opposite approaches.

Most of my work was done before Brian pointed out to me that the -Djava.class.path system property has influence on what is visible to the module system. In my case I am making sure everything runs in modules, both the test itself and the server. This might be overkill and forces a lot of definition of modules etc. which although made simple to set up will still probably be confusing to users new to module classloading.

In your case the server is started up using modules with the classpath and with the test itself and its dependencies using the app classpath, the -Djava.class.path system property controls that the app classpath is not visible to the server. I will look more into your solution now, but what you have is a lot simpler to set for the user so I think we should go with something based on that. I would still like a hook in Arquillian to be able to set tccl before starting it so that your logging abstraction is not necessary.

For now I would say that 'Dependencies' does exist and gets processed by the DUP, but we should not promote its usage by introducing an annotation for it. How about requiring the user to explicitly put it in the @Deployment artifact manifest like I do in ModuleAccessesBundleServiceTestCase

 

   private JavaArchive getClientModuleArchive() throws Exception

   {

      final JavaArchive archive = ShrinkWrap.create(JavaArchive.class, "example-xservice-client-module");

      archive.addClasses(EchoInvokerService.class, ClientModuleActivator.class);

      String activatorPath = "META-INF/services/" + ServiceActivator.class.getName();

      archive.addResource(getResourceFile("xservice/client-module/" + activatorPath), activatorPath);

      archive.setManifest(getResourceFile("xservice/client-module/" + JarFile.MANIFEST_NAME));

      return archive;

   }

 

This is something I was already doing for the demos. I don't really like it though, I think it would be nicer to be able to specify this somehow from within the test itself rather than having loads of manifest files in the resources but we can talk about that later.

Thomas Diesler wrote:

 

Ok, lets talk about this in more detail when you have something that runs and are generally happy with.

 

I generally think that this

@Dependency("org.jboss.logging"), @Dependency("org.jboss.logmanager")

 

is evil because results in jboss proprietary manifest headers that also has an equivalent standard, which is Require-Bundle

But they are jboss modules, not osgi bundles. We should only use osgi manifest entries if the thing we are producing is an actual osgi bundle, that actually uses osgi. Also, I don't think we should mandate usage of OSGi across the board with AS.

 

On the topic on why Require-Bundle is also bad see JBoss AS7 OSGi Integration half way down the page section

3.12.3 Issues With Requiring Bundles

As you know, I never really bought into the reasons behind packaged deps. I think OSGi is the only modularity spec that advocates them, and even they are moving away from them with their capabilities and requirements notion.

Jason Greene wrote:

 

As you know, I never really bought into the reasons behind packaged deps. I think OSGi is the only modularity spec that advocates them, and even they are moving away from them with their capabilities and requirements notion.

No - OSGi is not moving away from the package dependency model, that is an incorrect observation. The generic capabilities and requirements provide an additional level of declaring dependencies in cases where you don't have this information available as packages. Examples are the existence of an IoC (beans that are being injected typically don't have a package dependency on the IoC container) or some other type of extender.

OSGi is the most mature modularity system around today and although it supports other types of dependency declaration the package dependency model has been found the best dependency model by all OSGi experts that I know of.