14 Replies Latest reply on Jul 16, 2007 7:27 AM by Carlo de Wolf

    Ear deployment ordering broken in trunk

    Brian Stansberry Master

      Looks like EAR deployment ordering stuff done last summer for 4.0.5 is missing in trunk. This is resulting in the same types of test failures I had last year in http://jira.jboss.com/jira/browse/JBAS-3503.

      Seems like there are two problems:

      1) The http://jira.jboss.com/jira/browse/JBAS-2904 fix needs to be ported. In particular J2eeApplicationMetaData in trunk doesn not support the module-order config element.

      2) By default, the old implicit ordering is no longer occuring (e.g. deploy a -ds.xml before an ejb jar). There was some discussion last year in http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78376 of not having the implicit behavior be default in 5.0, so this might not be necessary.

      If this isn't something where there's a plan to completely redo how this works, I'll open a JIRA for the above.

        • 1. Re: Ear deployment ordering broken in trunk
          Dimitris Andreadis Master

          I think explicit ordering should be the default for EARs in JB5, but we most probably need a flag to fall back to the legacy behavior.

          But it depends if the new deployment framework can support the legacy behavior?

          • 2. Re: Ear deployment ordering broken in trunk
            Adrian Brock Master

            There shouldn't be any need to define the ordering.

            If the services (including ejb and web modules) have the correct dependencies
            it does not matter.

            However, deployment (rather than service) dependencies are on the road map
            http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4036378#4036378
            these will include "implicit" rules like:

            Russian doll ordering
            Explicit ordering
            All or nothing deployment (either all the subdeployments are deployed or none are)
            etc.

            In fact, we'll likely support "random order" so people can check
            that they have all dependencies defined (i.e. they are not being implicit)
            but this is more useful for testing our dependencies are properly specified.

            • 3. Re: Ear deployment ordering broken in trunk
              Carlo de Wolf Master

              I still don't get it for an EAR.

              In this case there is: ear = client jar + ejb jar (no metadata / javaee 5)

              Since it's going depth first, I don't get a chance to register dependencies, because they are unresolvable without the ejb jar being deployed (/ parsed).

              So here we see it dive into the client jar:

              2007-07-10 10:37:58,824 INFO [org.jboss.ejb3.deployers.AppClientScanningDeployer] mainClass = class com.sun.ts.tests.ejb30.bb.session.stateless.annotation.appexception.annotated.Client
              2007-07-10 10:37:58,876 DEBUG [org.jboss.ejb3.deployers.Ejb3ClientDeployer] deploy vfsfile:/home/carlo/work/jboss-head/build/output/jboss-5.0.0.Beta3/server/cts/tmp/jsr88/ejb3_stateless_appexception_annotated.ear/ejb3_stateless_appexception_annotated_client.jar
              2007-07-10 10:37:58,877 DEBUG [org.jboss.ejb3.deployers.Ejb3ClientDeployer] Creating client ENC binding under: ejb3_stateless_appexception_annotated_client
              2007-07-10 10:37:58,898 WARN [org.jboss.injection.EJBHandler] IGNORING DEPENDENCY: unable to find @EJB from interface only com.sun.ts.tests.ejb30.common.appexception.AppExceptionIF in application-client.xml of ejb3_stateless_appexception_annotated_clientnot used by any EJBs
              2007-07-10 10:37:58,913 WARN [org.jboss.injection.EJBHandler] IGNORING DEPENDENCY: unable to find @EJB from interface only com.sun.ts.tests.ejb30.common.appexception.RollbackIF in application-client.xml of ejb3_stateless_appexception_annotated_clientnot used by any EJBs


              • 4. Re: Ear deployment ordering broken in trunk
                Adrian Brock Master

                The depenendencies work at the STAGE level, not the flow level.

                They are primarily being introduced for classloading dependencies,
                so one deployment that depends upon another module won't create its classloader
                until a dependent classloader is constructed (and vice-versa at undeployment).

                Similary, there is a new "INSTALL" stage, which is where the real REAL deployers :-)
                should be. i.e. the ones that create (it should be register) the runtime objects.

                So you can do things like "All or Nothing" by requiring that all deployments in a group,
                (e.g. an EAR) have passed their "REAL" stage successfully before they are all moved to the
                "INSTALL" stage.

                In that context, "REAL" is not such a good name anymore. :-)

                • 5. Re: Ear deployment ordering broken in trunk
                  Carlo de Wolf Master

                  It's not about stages. Both ejb deployers and client deployers should have the same stage configuration.

                  It's about the client container (/ component) being dependent on stuff from a sister deployment unit. But the client container doesn't know which sister, or even if there is one. The only thing I can state for certain is that it wants to be last in line (sort of). It's the EAR deployment rules that are not being followed.
                  Note that there is no EAR metadata, so we have to come up with the EAR deployment order.

                  • 6. Re: Ear deployment ordering broken in trunk
                    Carlo de Wolf Master

                    If I modify EARStructure to sort the j2ee modules it all falls back into place.
                    Is that a way to go?

                    • 7. Re: Ear deployment ordering broken in trunk
                      Vicky Kak Master

                       

                      "wolfc" wrote:
                      In this case there is: ear = client jar + ejb jar (no metadata / javaee 5)

                      Can you specify the order of the deployment modules in the application.xml file and see if this works ?
                      Also you would have to use the module-order as strict in the jboss-app.xml .


                      • 8. Re: Ear deployment ordering broken in trunk
                        Adrian Brock Master

                         

                        "wolfc" wrote:
                        If I modify EARStructure to sort the j2ee modules it all falls back into place.
                        Is that a way to go?


                        NO. Implicit rules are broken as soon as somebody introduces other dependencies
                        that break the implicit rule.

                        • 9. Re: Ear deployment ordering broken in trunk
                          Adrian Brock Master

                           

                          "wolfc" wrote:
                          It's not about stages. Both ejb deployers and client deployers should have the same stage configuration.


                          Of course its about stages (proper dependencies across deployments).
                          You shouldn't even be binding the appclient into jndi until the EJB is ready to use

                          What if the EJB deployment fails do you still bind the appclient into jndi?
                          I don't think so, but its what happens in jboss-4.x

                          What if the EJB is waiting for some other dependency in a totally different
                          deployment (that maybe will be added later - because the user forgot)?
                          Do you bind the appclient, again NO.

                          It is just a trivial case of a more generic problem that I have explained many times
                          but I haven't seen any movement on fixing it.

                          Once I've done classloading dependencies we (or more probably I ;-)
                          can use it as an example on how to do proper jndi (and other registry)
                          dependencies - inside the MC dependency mechanism.

                          • 10. Re: Ear deployment ordering broken in trunk
                            Carlo de Wolf Master

                            Ah yes, silly me.

                            I need to register a dependency on the EJB interface I'm want to resolve later on. It's not a JNDI dependency, because I don't the JNDI name (yet). I'll have a hack at it, but I still don't see a resolution for the scenario where the interface is already deployed in another jar and also being deployed later on this ear.

                            Note that the appclient won't come up if it can't resolve the interfaces.

                            • 11. Re: Ear deployment ordering broken in trunk
                              Brian Stansberry Master

                              For the original issue of testsuite failures due to the missing dependency of EJB(2) deployments on the datasources they use, I've filed http://jira.jboss.com/jira/browse/JBAS-4548.

                              • 12. Re: Ear deployment ordering broken in trunk
                                Carlo de Wolf Master

                                I got a basic supply demain chain working. This one is without any fancy resolution. For that I need to write a new type of demand and supply meta data.

                                Another thing is that when demands are not satisfied, deployment stalls. How and where can I notify the user that I've unresolved dependencies?

                                • 13. Re: Ear deployment ordering broken in trunk
                                  Adrian Brock Master

                                  The checkComplete() on the MainDeployer lists all dependencies that are not satisfied.

                                  • 14. Re: Ear deployment ordering broken in trunk
                                    Carlo de Wolf Master

                                    Doh, I was afraid you would say that. I must have introduced a bug, because it doesn't do that for EJB 3 deployments.