1 2 3 Previous Next 40 Replies Latest reply on Sep 11, 2008 7:37 PM by theben Go to original post
      • 15. Re: EJB/War deployer ordering problem
        starksm64

        What we talked about was to order war deployment contexts after all others in the deployment using the relative order as an implicit dependency. If a war starts after an ejb deployment which depends on a ds, the war is also started after the ds.

        We don't support the jndi event notification. Seems like a seam annotation deployer is needed to pull these dependencies into the JBossWebMetaData.

        • 16. Re: EJB/War deployer ordering problem
          alesj

           

          "scott.stark@jboss.org" wrote:
          What we talked about was to order war deployment contexts after all others in the deployment using the relative order as an implicit dependency.

          Sure, if both -ds.xml and .war are in the same deployment.
          But usually they are in two separate deployments.

          We can order - and that's what I did - top deployments that are picked by a current scan cycle of our HDScanner.
          But if the two deployments from above are picked in two different cycles of HDScanner, -ds.xml being in the 2nd one, it will fail again.

          "scott.stark@jboss.org" wrote:
          If a war starts after an ejb deployment which depends on a ds, the war is also started after the ds.

          That's not the case here.
          Probably since there are no ejbs dependencies on the .war.
          Some one is not putting the ejbs into JBossWebMetaData.
          Since I can see that a WebModule has dependencies from JBWMD in the AbstractWarDeployer.deployWebModule method.

          Basically that's the whole problem, we need to see why those dependencies are not in place.
          The relative order from above has no meaning if this is done as it should be.

          "scott.stark@jboss.org" wrote:

          Seems like a seam annotation deployer is needed to pull these dependencies into the JBossWebMetaData.

          Your 'seam annotation deployer' is Seam Scanner, which is triggered from ServletContextListener and by that has no knowledge about MC and JBWMD what so ever.

          • 17. Re: EJB/War deployer ordering problem
            alesj

             

            "alesj" wrote:

            Basically that's the whole problem, we need to see why those dependencies are not in place.

            2008-02-03 01:25:04,546 DEBUG [org.jboss.web.tomcat.service.deployers.TomcatDeployer] jboss.web.deployment:war=/seam-dvd - null

             Collection<String> depends = metaData.getDepends();
             log.debug(name + " - " + depends);
            


            Are EJBs not put to JBWMD by design or is this a bug?

            • 18. Re: EJB/War deployer ordering problem
              starksm64

               

              "alesj" wrote:

              We can order - and that's what I did - top deployments that are picked by a current scan cycle of our HDScanner.
              But if the two deployments from above are picked in two different cycles of HDScanner, -ds.xml being in the 2nd one, it will fail again.

              This will always fail, even with dependencies. With dependencies it will be redeployed when the missing ds does show up.

              "alesj" wrote:

              Some one is not putting the ejbs into JBossWebMetaData.
              Since I can see that a WebModule has dependencies from JBWMD in the AbstractWarDeployer.deployWebModule method.

              Only a war which explicitly states its dependencies, or the war deployer scanning other contexts for ejbs can add these. The getDepends() value is explicit dependencies declared in a jboss-web.xml descriptor. There is no magic here.

              "alesj" wrote:

              Your 'seam annotation deployer' is Seam Scanner, which is triggered from ServletContextListener and by that has no knowledge about MC and JBWMD what so ever.

              which is too late to be adding dependencies on other deployments. There could be an integration deployer that uses the seam scanner to identify dependencies.


              • 19. Re: EJB/War deployer ordering problem
                alesj

                 

                "scott.stark@jboss.org" wrote:
                "alesj" wrote:

                We can order - and that's what I did - top deployments that are picked by a current scan cycle of our HDScanner.
                But if the two deployments from above are picked in two different cycles of HDScanner, -ds.xml being in the 2nd one, it will fail again.

                This will always fail, even with dependencies. With dependencies it will be redeployed when the missing ds does show up.

                Why would it get redeployed?
                Wouldn't just wait till the ds is started/installed?

                • 20. Re: EJB/War deployer ordering problem
                  starksm64

                  Finish installing is what I meant by redeployed.

                  • 21. Re: EJB/War deployer ordering problem
                    alesj

                    Why would it fail?

                    • 22. Re: EJB/War deployer ordering problem
                      starksm64

                      Every scan is followed by a check incomplete call. The deployment won't be in an installed state == a failure.

                      • 23. Re: EJB/War deployer ordering problem
                        alesj

                         

                        "scott.stark@jboss.org" wrote:
                        Every scan is followed by a check incomplete call. The deployment won't be in an installed state == a failure.

                        Ah yes, and imagine that I wrote that part. :-)

                        OK, how should we proceed with introducing dependencies to that WebModule's ServiceMetaData?

                        We can put in some global metadata attachment to top level unit, which would hold the likes of EJBs, WS, ...
                        And when adding explicit dependencies from JBWMD, we could add those as well.
                        Too of a hack?

                        • 24. Re: EJB/War deployer ordering problem
                          starksm64

                          I'm not sure what you have done. I don't think just ordering top-level deployments is enough/solves the problem we are trying to solve. We want the war deployment contexts to have a relative order > any other context by default. As I understand it this will start these last, which means the ejbs in the ear containing the war will have been started.

                          I don't see that the top-level ordering is helping with anything. If WARStructure just sets the relativeOrder to 99, and this is propagated to the AbstractDeploymentContext, are the war context being started after the ejb contexts in the seam ear?

                          • 25. Re: EJB/War deployer ordering problem
                            alesj

                             

                            "scott.stark@jboss.org" wrote:

                            I don't see that the top-level ordering is helping with anything. If WARStructure just sets the relativeOrder to 99, and this is propagated to the AbstractDeploymentContext, are the war context being started after the ejb contexts in the seam ear?

                            Yes.
                            Not started, deployed.
                            But the ejbs are waiting for ds, which is not in ear.
                            Where the war doesn't have anything that is delaying it to be installed.
                            And only then is ds deployed.

                            But if we order top deployments, so that ds is before ear, ds will get fully installed, then ejbs will get fully installed, and war is already being fully installed. But in this case Seam will be able to find the ejb, since it was already fully installed.

                            • 26. Re: EJB/War deployer ordering problem
                              starksm64

                               

                              "alesj" wrote:
                              Not started, deployed.
                              But the ejbs are waiting for ds, which is not in ear.
                              Where the war doesn't have anything that is delaying it to be installed.


                              Ok, then what we need is an EjbContextDependencyItem that waits on the ejb deployment context to reach the installed state. This should be created for any deployment context with a JBossMetaData attachment.


                              • 27. Re: EJB/War deployer ordering problem
                                alesj

                                 

                                "scott.stark@jboss.org" wrote:
                                Ok, then what we need is an EjbContextDependencyItem that waits on the ejb deployment context to reach the installed state. This should be created for any deployment context with a JBossMetaData attachment.

                                This could work.
                                We then need to create dependencies from ejb deployment context to all of its components.
                                And also making war deployment context depend on all ear's ejb deployment contexts.

                                • 28. Re: EJB/War deployer ordering problem
                                  starksm64

                                  I don't think we should have to do that? The deployment context state should not reach DeploymentState.DEPLOYED unless all its components are installed, right?

                                  • 29. Re: EJB/War deployer ordering problem
                                    alesj

                                     

                                    "scott.stark@jboss.org" wrote:
                                    I don't think we should have to do that? The deployment context state should not reach DeploymentState.DEPLOYED unless all its components are installed, right?

                                    Hmm, I don't think we currently introduce any dependencies between deployment context and its components.
                                    I'll have a look, but I don't remember seeing any dependency items being put on DeploymentControllerContext.