4 Replies Latest reply on May 11, 2011 3:24 AM by Radai Rosenblatt

    adding beans.xml to arquillian @Deployment causes deployment issues

    Radai Rosenblatt Newbie

      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)

        • 1. Re: adding beans.xml to arquillian @Deployment causes deployment issues
          Todd Morrison Newbie

          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.

          • 2. Re: adding beans.xml to arquillian @Deployment causes deployment issues
            Radai Rosenblatt Newbie

                @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)