14 Replies Latest reply on Apr 19, 2010 5:42 AM by Pete Muir

    JIRA updated

    Pete Muir Master



      Aslak and I have been through the meetings and the forums and made sure we have JIRA issues for all ideas discussed. I've also been through and reviewed the components, and bucketed the issues into releases. I've kept the releases pretty fine grained (past alpha2), and tried to give them meaningful descriptions. We can change the order of releases, or the purpose, or the granularity :-)






      With this in mind, lets try to set a date to get alpha1 out!

        • 1. Re: JIRA updated
          Dan Allen Master

          Excellent. I'm excited to get to alpha1, so I say let's move forward.


          The only change that I would suggest before alpha1 is to rename the container artifactIds as follows, just so that they are right to start with:


          • arquillian-jbossas-remote-60
          • arquillian-jbossas-remote-51
          • arquillian-jbossas-embedded-60
          • arquillian-glassfish-embedded-v3


          Or should the prefix be "container-"?


          Also, shouldn't the groupId be org.jboss.arquillian.container rather than just org.jboss.arquillian? My concern is that container is not represented in either the groupId or the artifactId, so it is sort of ambiguous.

          • 2. Re: JIRA updated
            Aslak Knutsen Master

            we should do this before alpha-1, just so we don't start alpha-2 with a big refactoring.


            I suggest:


            groupid: org.jboss.arquillian.container

            artifactid: jbossas-remote-60, jbossas-remote-51, jbossas-embedded-60, glassfish-embedded-v3


            And we move the container-* folders down a level to contianer/jboss-as...


            I can get on this tomorrow morning if accepted .. ?

            • 3. Re: JIRA updated
              Dan Allen Master



              Except that I think we should go ahead and keep the "arquillian-" prefix on the artifactId because, remember, that becomes the name of the JAR file and it is customary to qualify the JAR w/ the project name...at least that's what I'm seeing when I look at other JBoss projects.




              groupId: org.jboss.arquillian.container

              artifactId: arquillian-jbossas-remote-60, arquillian-jbossas-remote-51, arquillian-jbossas-embedded-60, arquillian-glassfish-embedded-v3

              • 4. Re: JIRA updated
                Aslak Knutsen Master

                excellent point!





                One little problem tho, all the articles use the old names.


                Using Arquillian to test a possible bug in Weld - http://community.jboss.org/message/527086

                Testing a JMX Portable Extension for CDI - http://community.jboss.org/message/529016

                Seam 3 JMS Module Testing with Arquillian - http://community.jboss.org/wiki/Seam3JMSModuleTestingwithArquillian

                With admin rights I guess we can just edit them ?
                • 5. Re: JIRA updated
                  Aslak Knutsen Master

                  Project structure reorg:








                  • 6. Re: JIRA updated
                    Dan Allen Master

                    Nice work.


                    I've got a few nit pick items. Perhaps you just haven't gotten to the last two yet.


                    1. I would recommend renaming packagers/java-ee to packagers/javaee since that's how Snoracle abbreviates it (see http://java.sun.com/javaee/)
                    2. The JBoss AS containers should be prefixed jbossas (to be consistent w/ http://jboss.org/jbossas)
                    3. GlassFish still needs the v3 qualifier


                    This is a nice step forwards towards looking sharp!

                    • 8. Re: JIRA updated
                      Dan Allen Master

                      I would say yes for openejb. I'm not sure about weld, though. Maybe Pete can chime in.


                      The motivation for adding the major version number is that different major versions of application servers tend to have completely different deployment APIs. There is no real standard there. What works for JBoss AS 6 may not work for JBoss AS 7. (Btw, I'm not sure we need 51 and 60, rather just 5 and 6). Again, I'd like to hear what Pete has to say. The idea is to minimize the artifacts, but w/o causing conflicts.


                      With weld, we are trying to standardize the bootstrap API, so it is much less likely to change (meaning we wouldn't need two separate implementations).

                      • 9. Re: JIRA updated
                        Pete Muir Master

                        Sorry, to respond so late.


                        Unfortunately JBoss AS has a habit of changing it's deployment API between every release, minor major, so I guess we need to do both 51 and 60.


                        With Weld, Aslak, what deployment/bootstrap API are you using?

                        • 10. Re: JIRA updated
                          Aslak Knutsen Master



                                WeldBootstrap bootstrap = new WeldBootstrap();
                                bootstrap.startContainer(Environments.SE, deployment, new ConcurrentHashMapBeanStore())
                                WeldManager manager = bootstrap.getManager(beanArchive);




                          • 11. Re: JIRA updated
                            Dan Allen Master

                            Hmm, that could be simplified if Weld#initialize() were overloaded to accept a deployment and WeldContainer#getBeanManager() returned a WeldManager. With these changes in place, the bootstrap code would be simplified to:


                            WeldContainer weld = new Weld().initialize(deployment);
                            WeldManager manager = weld.getBeanManager();


                            Should we create an issue for this change in both Weld SE and Arquillian?

                            • 12. Re: JIRA updated
                              Aslak Knutsen Master

                              Yea i noticed the same when I creating the Weld Container. I made the patch already, but never spoke to Peter Royle about it.




                              Index: src/main/java/org/jboss/weld/environment/se/Weld.java
                              --- src/main/java/org/jboss/weld/environment/se/Weld.java     (revision 6123)
                              +++ src/main/java/org/jboss/weld/environment/se/Weld.java     (working copy)
                              @@ -20,6 +20,7 @@
                              import org.jboss.weld.bootstrap.api.Bootstrap;
                              import org.jboss.weld.bootstrap.api.Environments;
                              import org.jboss.weld.bootstrap.spi.BeanDeploymentArchive;
                              +import org.jboss.weld.bootstrap.spi.Deployment;
                              import org.jboss.weld.context.api.BeanStore;
                              import org.jboss.weld.context.api.helpers.ConcurrentHashMapBeanStore;
                              import org.jboss.weld.environment.se.beans.InstanceManager;
                              @@ -68,12 +69,20 @@
                                  public WeldContainer initialize()
                              +      return initialize(
                              +            new SEWeldDeployment() { }
                              +      );
                              +   }
                              -      SEWeldDeployment deployment = new SEWeldDeployment()
                              -      {
                              -      };
                              +   /**
                              +    * Boots Weld and creates and returns a WeldContainer instance, through which
                              +    * beans and events can be accesed.
                              +    */
                              +   @PostConstruct
                              +   public WeldContainer initialize(Deployment deployment)
                              +   {
                                     bootstrap.startContainer(Environments.SE, deployment, this.applicationBeanStore);
                              -      final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().get(0);
                              +      final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().iterator().next();
                                     this.manager = bootstrap.getManager(mainBeanDepArch);
                              @@ -84,7 +93,6 @@
                                     InstanceManager instanceManager = WeldManagerUtils.getInstanceByType(manager, InstanceManager.class);
                                     return new WeldContainer(instanceManager, manager);





                              I think the issue that I had with it was that the API didn't really match.


                              Deployment != BeanManager


                              It would be a odd limitation in the Weld SE API to only support the first BeanDeploymentArchive


                                    final BeanDeploymentArchive mainBeanDepArch = deployment.getBeanDeploymentArchives().get(0);



                              So I ended up copying how Weld SE did it instead..

                              • 13. Re: JIRA updated
                                Pete Muir Master

                                I don't think this is a suitable change to Weld SE - a standard Java SE container has no notion of non-homogenous deployments that I know of, so specifying the deployment structure is uncessary. I also don't think leaking WeldManager onto the Weld SE SPI is a good idea - this is part of the Weld SPI (for container integration) and so shouldn't be used by most containers


                                The current approach is definitely the one we intended you to take!

                                • 14. Re: JIRA updated
                                  Pete Muir Master

                                  Talking to Aslak on IRC, we reached the following conclusions:


                                  • Current support should be rebadged Weld SE container
                                  • Should add support for a Weld "EE mocks" container that mocks out the EE SPI (like the current TestContainer)
                                  • TestContainer and mocks should be moved into this module when the Weld core tests + TCK is converted to Arqullian (from weld-core-tests)