1 2 Previous Next 20 Replies Latest reply on Mar 14, 2008 11:31 AM by adrian.brock

    JBDEPLOY-3 issues

    alesj

      JBMICROCONT-185 is the old version of JBDEPLOY-3.

      What's to do with the DeployerProtocolUnitTestCase's TODO?
      If I uncomment the code, the test still works.
      I guess this is the relevant discussion:
      - http://www.jboss.com/?module=bb&op=viewtopic&t=123258

      New JIRA for types removal?

        • 1. Re: JBDEPLOY-3 issues
          alesj

          Regarding this:
          - http://jira.jboss.com/jira/browse/JBDEPLOY-10

          What kind of annotations should we scan for?
          I currently just ported what is already in the real EARStructure (in AS5_trunk), which is just recognizing ear's children.

          With annotation scanning, I really think we should do this in generic fashion, once for all utils/frameworks that depend on annotation existence - e.g. EJB3, Seam, ...
          Providing the hooks for them to plug-in into our generic solution and get pre-scanned results. Or making this lazy, and let them trigger the initial scanning.

          • 2. Re: JBDEPLOY-3 issues

             

            "alesj" wrote:
            JBMICROCONT-185 is the old version of JBDEPLOY-3.

            What's to do with the DeployerProtocolUnitTestCase's TODO?
            If I uncomment the code, the test still works.
            I guess this is the relevant discussion:
            - http://www.jboss.com/?module=bb&op=viewtopic&t=123258

            New JIRA for types removal?


            The types should be somewhere in the Managed* api not the deployment api.
            Especially since I don't want people doing hacky things in the deployers
            based on getTypes() ;-)

            • 3. Re: JBDEPLOY-3 issues

               

              "alesj" wrote:
              Regarding this:
              - http://jira.jboss.com/jira/browse/JBDEPLOY-10

              What kind of annotations should we scan for?
              I currently just ported what is already in the real EARStructure (in AS5_trunk), which is just recognizing ear's children.

              With annotation scanning, I really think we should do this in generic fashion, once for all utils/frameworks that depend on annotation existence - e.g. EJB3, Seam, ...
              Providing the hooks for them to plug-in into our generic solution and get pre-scanned results. Or making this lazy, and let them trigger the initial scanning.


              Yes the deployers should provide a mechanism where relevant other deployers
              can take part in a single annotation scan (or avoid the scan althogether
              if everybody agrees the deployment is 'metadata" complete).

              But create a different thread for different issues.

              • 4. Re: JBDEPLOY-3 issues
                alesj

                 

                "adrian@jboss.org" wrote:
                The types should be somewhere in the Managed* api not the deployment api.
                Especially since I don't want people doing hacky things in the deployers
                based on getTypes() ;-)

                OK, I'll go ahead and remove them from deployers.
                And then discuss it with Scott where in Managed* he wants them.

                • 5. Re: JBDEPLOY-3 issues
                  alesj

                   

                  "adrian@jboss.org" wrote:

                  But create a different thread for different issues.

                  This is just the initial teaser, to see if the discussion spins off. :-)

                  • 6. Re: JBDEPLOY-3 issues
                    alesj

                     

                    "alesj" wrote:

                    OK, I'll go ahead and remove them from deployers.

                    I removed it from Deployment(Unit|Context), but I still left Deployer::getType, since I guess that is what Scott will still need to hook up with Managed* api.

                    • 7. Re: JBDEPLOY-3 issues
                      starksm64

                      Implementations of org.jboss.profileservice.spi.DeploymentRepository.getDeploymentNamesForType are looking to the VFSDeployment.getType, not Deployer.getType. There are some deployer beans.xml that are setting the type property, so they would need to be updated to remove Deployer.getType.

                      The org.jboss.managed.api.ManagedDeployment has a types notion, so support will have to be based on that.

                      • 8. Re: JBDEPLOY-3 issues
                        alesj

                         

                        "scott.stark@jboss.org" wrote:
                        Implementations of org.jboss.profileservice.spi.DeploymentRepository.getDeploymentNamesForType are looking to the VFSDeployment.getType, not Deployer.getType.

                        Sure, but that's exactly what was asked to be removed.
                        The Deployment(Unit|Context) shouldn't have the types.

                        "scott.stark@jboss.org" wrote:
                        There are some deployer beans.xml that are setting the type property, so they would need to be updated to remove Deployer.getType.

                        So, you're saying you wont be needing Deployer::getType?

                        "scott.stark@jboss.org" wrote:

                        The org.jboss.managed.api.ManagedDeployment has a types notion, so support will have to be based on that.

                        Yup, but I thought this would use Deployer::getType to build the ManagedDeployment with the right types.

                        • 9. Re: JBDEPLOY-3 issues
                          starksm64

                          No, the org.jboss.deployers.spi.deployer.managed.ManagedDeploymentCreator relies on DeploymentUnit or the unit ManagedObject set:

                          public interface ManagedDeploymentCreator
                          {
                           /**
                           * Build up the deployment management view.
                           * @param unit - the deployment unit to process
                           * @param md - the unit ManagedDeployment
                           */
                           public ManagedDeployment build(DeploymentUnit unit, Map<String, ManagedObject> unitMOs,
                           ManagedDeployment parent);
                          }
                          


                          If type is not part of DeploymentUnit, then a ManagementDeployment annotation would have to be added to use with the ManagedObjects.


                          • 10. Re: JBDEPLOY-3 issues

                             

                            "scott.stark@jboss.org" wrote:

                            If type is not part of DeploymentUnit, then a ManagementDeployment annotation would have to be added to use with the ManagedObjects.


                            That's what we agreed before isn't it?
                            The "type" is a notion used by the management layer for grouping,
                            it has no use in the deployers and is even probably difficult to
                            set effectively in some usecases.

                            • 11. Re: JBDEPLOY-3 issues
                              alesj

                               

                              "adrian@jboss.org" wrote:
                              The "type" is a notion used by the management layer for grouping,
                              it has no use in the deployers and is even probably difficult to
                              set effectively in some usecases.

                              Drop it out of deployers then as well?

                              • 12. Re: JBDEPLOY-3 issues
                                starksm64

                                Yes.

                                • 13. Re: JBDEPLOY-3 issues
                                  alesj

                                   

                                  "alesj" wrote:
                                  Drop it out of deployers then as well?

                                  This was removed.
                                  A fair warning: all AS5 deployers that define type should get that removed from xml, since setType is not longer there ;-)

                                  e.g. from bootstrap-beans.xml
                                   <bean name="BeanDeployer" class="org.jboss.deployers.vfs.deployer.kernel.BeanDeployer">
                                   <!--<property name="type">beans</property>-->
                                   </bean>
                                  


                                  • 14. Re: JBDEPLOY-3 issues

                                    Can you put setType() back please, but re-implement it like this:

                                    @Deprecated
                                    public void setType(...)
                                    {
                                     log.warn("Types should be set using <mechanism here/> for " + this);
                                    }
                                    


                                    That is unless you want to go through all the deployers that exist
                                    to get jboss-head to compile/boot. :-)

                                    1 2 Previous Next