7 Replies Latest reply on Nov 24, 2007 11:32 AM by Adrian Brock

    2.0.0-beta7 release

    Adrian Brock Master

      I want to do a 2.0.0-beta7 release today (or over the weekend).

      Speak now if you think I shouldn't or if you have something that needs to go in it.

      I moved all the closed issues from CR1 into this release in JIRA.

        • 1. Re: 2.0.0-beta7 release
          Ales Justin Master

          I have some things that I didn't commit yet, but they can wait. :-)

          My only concern regarding beta7 release is this issue:
          - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=124324

          This one probably needs EJB resolution and not MC:
          - http://www.jboss.org/index.html?module=bb&op=viewtopic&t=124292
          And as such requires current changes/fixes to the deloyers.

          • 2. Re: 2.0.0-beta7 release
            Adrian Brock Master

             

            "alesj" wrote:
            I have some things that I didn't commit yet, but they can wait. :-)


            Are they changes required for JBossAS beta3?

            • 3. Re: 2.0.0-beta7 release
              Ales Justin Master

               

              "adrian@jboss.org" wrote:

              Are they changes required for JBossAS beta3?

              No.
              I was waiting for some reply from the POJO forum.
              And as such continued/started working on JBMICROCONT-217, 219, 220.

              I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS.
              But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ...

              • 4. Re: 2.0.0-beta7 release
                Adrian Brock Master

                 

                "alesj" wrote:

                I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS.
                But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ...


                That's to tidyup the stupid way the ejb-jar.xml and jboss.xml (and equivalents
                for ears and wars) are parsed.

                1) They're in seperate parsing deployers which isn't going to work
                properly when you have predefined metadata. The hack Scott put in
                will always reparse jboss.xml

                2) Some of the behaviour (like the merging and initialization) shouldn't be in there.
                Again, won't work properly with the profile service.

                Related to those mistakes, I noticed somebody re-introduced
                the hack of overridding createMetaData() again.
                I've got a good mind to make that method final. Then people can't
                keep doing it wrong. :-)

                What it should do is parse the two together in one parsing deployer
                but only if there is no metadata already preinstantiated.

                The initialization like pulling out the loaderRepositoryConfig and "wrapping"
                with standardjboss.xml should be in a seperate deployer since they are
                done regardless of whether you are given metadata or you parse it.

                I don't think this needs doing for beta3. It's just implementation detail
                to make programmatic deployment work.

                • 5. Re: 2.0.0-beta7 release
                  Scott Stark Master

                   

                  "adrian@jboss.org" wrote:
                  "alesj" wrote:

                  I also looked at the http://jira.jboss.com/jira/browse/JBMICROCONT-184, which seems to be better candidate for earlier inclusion into JBossAS.
                  But would need some guidance, specially with the current metadata rewrite, and how merging is/should be handled ...


                  That's to tidyup the stupid way the ejb-jar.xml and jboss.xml (and equivalents
                  for ears and wars) are parsed.

                  1) They're in seperate parsing deployers which isn't going to work
                  properly when you have predefined metadata. The hack Scott put in
                  will always reparse jboss.xml


                  The reparse option should not be needed for any parsing deployer with the metadata rewrite because the metadata has one to one representations with the descriptors, and merged views into the jboss metadata. For cases where multiple descriptors are merged like standardjboss.xml, jboss.xml, there are wrapping proxy classes that combine the two views.


                  • 6. Re: 2.0.0-beta7 release
                    Ales Justin Master

                    This is the change I was talking about (AbstractRealDeployer):

                     public final void deploy(DeploymentUnit unit) throws DeploymentException
                     {
                     internalDeploy(unit);
                    
                     if (isControllerContextNameCandidate(unit))
                     {
                     addControllerContextName(unit);
                     }
                     }
                    
                     /**
                     * Should we set controller context name on unit?
                     *
                     * @param unit the dpeloyment unit
                     * @return true if we should use unit's name as controller context name
                     */
                     protected boolean isControllerContextNameCandidate(DeploymentUnit unit)
                     {
                     return useUnitName && unit.isComponent();
                     }
                    
                     /**
                     * Deploy a deployment
                     *
                     * @param unit the unit
                     * @throws DeploymentException for any error
                     */
                     protected abstract void internalDeploy(DeploymentUnit unit) throws DeploymentException;
                    
                     /**
                     * Add controller context name.
                     *
                     * @param unit the deployment unit
                     */
                     protected void addControllerContextName(DeploymentUnit unit)
                     {
                     unit.addControllerContextName(unit.getName());
                     }
                    
                     /**
                     * Remove controller context name.
                     *
                     * @param unit the deployment unit
                     */
                     protected void removeControllerContextName(DeploymentUnit unit)
                     {
                     unit.removeControllerContextName(unit.getName());
                     }
                    
                     public final void undeploy(DeploymentUnit unit)
                     {
                     try
                     {
                     if (isControllerContextNameCandidate(unit))
                     {
                     removeControllerContextName(unit);
                     }
                     }
                     catch (Throwable t)
                     {
                     if (log.isTraceEnabled())
                     log.trace("Exception while removing unit name: " + t);
                     }
                    
                     internalUndeploy(unit);
                     }
                    
                     /**
                     * Undeploy an deployment
                     *
                     * @param unit the unit
                     */
                     protected void internalUndeploy(DeploymentUnit unit)
                     {
                     // nothing
                     }
                    
                     /**
                     * Should we use unit name for controller context name.
                     *
                     * @return true if usage is allowed
                     */
                     public boolean isUseUnitName()
                     {
                     return useUnitName;
                     }
                    
                     /**
                     * Set use unit name for controller context name.
                     *
                     * @param useUnitName flag to allow unit name usage
                     */
                     public void setUseUnitName(boolean useUnitName)
                     {
                     this.useUnitName = useUnitName;
                     }
                    


                    Since I want to explicitly force this name registration on the real deployers - hence making the deploy/undeploy methods final.


                    • 7. Re: 2.0.0-beta7 release
                      Adrian Brock Master

                      I couldn't do the maven release because of this issue:
                      http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4107488#4107488

                      I've tagged it in svn and released it manually in the old repository for the appserver.