adding beans.xml to arquillian @Deployment causes deployment issues

[hatchetman82]

i have a @Deployment method that returns an EAR archive.

i've just added an empty beans.xml to that ear (i intend to start playing around with CDI), which results in this:

org.jboss.weld.exceptions.DeploymentException: WELD-000069 An interceptor must have at least one binding, but org.jboss.shrinkwrap.descriptor.example.InterceptorSample has none, **ERROR**

        at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1370) [:2.2.1.GA]

        at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1316) [:2.2.1.GA]

        at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:968) [:2.2.1.GA]

        at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.checkComplete(MainDeployerPlugin.java:82) [:6.1.0-SNAPSHOT]

        at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.checkComplete(ProfileControllerContext.java:138) [:0.2.2]

        at org.jboss.profileservice.plugins.deploy.actions.DeploymentStartAction.doPrepare(DeploymentStartAction.java:104) [:0.2.2]

        at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:101) [:0.2.2]

        at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]

        at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]

        at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]

        at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]

        at org.jboss.profileservice.plugins.deploy.AbstractDeployHandler.startDeployments(AbstractDeployHandler.java:168) [:0.2.2]

        at org.jboss.profileservice.management.upload.remoting.DeployHandlerDelegate.startDeployments(DeployHandlerDelegate.java:74) [:6.1.0-SNAPSHOT]

        at org.jboss.profileservice.management.upload.remoting.DeployHandler.invoke(DeployHandler.java:156) [:6.1.0-SNAPSHOT]

        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) [:]

        at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) [:]

        at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) [:]

        at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) [:]

        at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) [:]

looking at the ear produced by arquillian, the problematic class (org.jboss.shrinkwrap.descriptor.example.InterceptorSample) is in arquillian-core.jar (added by arquillian to the ear's /lib) and is part of shrinkwrap-descriptors-api-0.1.4

how do i make the deployment work ? either by removing this Sample class (what is it doing there to begin with?) or by working around it using some beans.xml voodoo? (im new to CDI)

[toddpi314]

Can you post your test class? Specifically how you are building up the ShrinkWrap?

Here is one that works for me:

@RunWith(Arquillian.class)
public class ConfirmedMemberRegistrationTest {
  @Deployment
          public static Archive<?> createTestArchive() {
                    return ShrinkWrap
                                        .create(WebArchive.class, "test.war")
                                        .addPackages(true, "com.mememe.modules")
                                        .addPackages(true, "com.mememe.test")
                                        .addAsLibrary(
                                                            MavenArtifactResolver
                                                                                .resolve("org.jasypt:jasypt:1.7.1"))
                                        .addAsResource("test-persistence.xml",
  "META-INF/persistence.xml")
                                        .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
          }

  @Inject
  AllYourBaseProvider allYourBaseProviderImpl;


@Test
public void woot()
{
     Assert.assertTrue(allYourBaseProviderImpl.isWorking());
}
}

Here, there is an example of the popular 'addPackages'... the clever MavenArtifactResolver that Dan wrote and the Asset descriptor that will totally blow up your deployment if not present.

[hatchetman82]

    @Deployment

    public static Archive createTestArchive() {

        JavaArchive javaArchive = ShrinkWrap.create(JavaArchive.class, "test.jar");

        EnterpriseArchive moduleFile = ShrinkWrap.create(EnterpriseArchive.class);

        for (File currLib : new File("../interfaces/target/alternateLocation").listFiles()){

            if(currLib.getName().endsWith(".jar")) {

                moduleFile.addAsLibraries(ShrinkWrap.createFromZipFile(JavaArchive.class, currLib));

            }

        }

        javaArchive.addPackages (true, new Filter<ArchivePath>()

        {

            @Override

            public boolean include(ArchivePath object)

            {

                return object.get().startsWith(APP_TEST_PKG);

            }

        }, Package.getPackages());

        moduleFile.addAsManifestResource("jboss-app.xml");

        moduleFile.addAsManifestResource("jboss-classloading.xml");

        moduleFile.addAsManifestResource("beans.xml");

        moduleFile.addAsLibraries(javaArchive);

        return moduleFile;

    }

this is done in an abstract superclass for our system tests module. the tests rely on the actual production *.ear/*.rar/*.war files already being present in /deploy, and constructs a test *.ear that contains the interface jars to all the @Local interfaces for everything (we pull those from "../interfaces/target/alternateLocation" above, where they are put by the maven build). this test ear it set in the same classloader domain as the production artifacts (config in jboss-app and jboss-classloading xml files, same config in production artifacts) to allow injecting those @Local beans (because without those tweaks its a different ear).

the offending java class though is added after all this by arquillian into the resulting ear archive.

dropping the "beans.xml" line results in a working test deployment (offending file is still in arquillian-core.jar, just not picked up by CDI)

[aslak]

This was a bug in the ShrinkWrap Descriptors project. Try to update the version used,

https://repository.jboss.org/nexus/content/groups/public/org/jboss/shrinkwrap/descriptors/shrinkwrap-descriptors-api/0.1.6/

[hatchetman82]

thanks.