1 2 Previous Next 29 Replies Latest reply on Nov 4, 2008 10:21 AM by adrian.brock Go to original post
      • 15. Re: SAR Deployment Deployers Ordering
        alesj

         

        "richard.opalka@jboss.com" wrote:
        "alesj" wrote:

        What do you have in your .sar? MBeans?

        No, just web archive (incorporating WebService endpoints our deployers operate with)

        Try with renaming first,
        and/or do some investigation around jboss-classloading.xml,
        on how you can declare dependency on module / jar:
        - https://jira.jboss.org/jira/browse/JBCL-10

        • 16. Re: SAR Deployment Deployers Ordering
          ropalka

          After short investigation deployers (not deployment) is my real problem.
          I noticed that .sar archives are deployed first (thus deployers operate on them first too). Deployers are executed first and then archives are scheduled for deployment.

          My problem is that the .sar archive can incorporate nested EJB or Web deployments representing Web Service deployments. Thus our deployers operate on these nested archives present in .sar archives.

          Our real problem is that our WebServices deployer depends on JBossWebMetaData ctx classloader which is null in time frame of executing the deployers chain for all .sar archives being processed by deployers.

          • 17. Re: SAR Deployment Deployers Ordering
            ropalka
            • 18. Re: SAR Deployment Deployers Ordering
              alesj

               

              "richard.opalka@jboss.com" wrote:
              "alesj" wrote:

              http://java.dzone.com/articles/a-look-inside-jboss-microconta

              I'm reading it now ;)

              I doubt it will help with the problem above, but it cannot hurt. :-)

              Perhaps you can use DeploymentUnit::getResourceClassLoader while the _real_ ClassLoader is not yet resolved?
              But make sure this usage is legit, not actually a hack while doing deployers in a wrong way. ;-)

              • 19. Re: SAR Deployment Deployers Ordering

                I'm going to reset this conversation in the next post,
                but first let me try to summarise the description of this problem
                from this long thread and explain what I think is really happening
                (and tell you how you would do exactly what you are asking for
                although it is the wrong way to do it).

                So you can tell me where I have misunderstood .... :-)

                You have a sar that contains a war, e.g. like the web-console

                [ejort@warjort management]$ ls -l console-mgr.sar/
                total 1560
                -rw-rw-r-- 1 ejort ejort 142692 Nov 3 20:59 console-mgr-classes.jar
                -rw-rw-r-- 1 ejort ejort 307601 Nov 3 20:59 jcommon.jar
                -rw-rw-r-- 1 ejort ejort 1098048 Nov 3 20:59 jfreechart.jar
                drwxrwxr-x 2 ejort ejort 4096 Nov 3 20:59 META-INF
                drwxrwxr-x 7 ejort ejort 4096 Nov 3 21:00 web-console.war
                


                This **naively** means that the webapp in web-console.war needs to be
                "deployed" after jbossweb.sar
                But if you look at the logging you'll find this isn't what happens in the deployer layer.

                This actually hasn't changed in this basic characteristic between jboss4 and jboss5
                Since management/console-mgr.sar (the top level deployment name) is before
                jbossweb.sar it will go through the deployers first (including all its subdeployments).

                ASIDE: What has changed in JBoss5 is that the deployers are now done in stages
                so you can be sure the classloader for jbossweb.sar is available in the REAL
                stage for all other deployments in deploy.
                This makes NoClassDefFoundErrors due to deployment ordering less likely in JBoss5
                even when you don't use the new classloading dependencies.

                So why isn't this an issue? The answer is that the deployers don't create
                the webapp. What they do create is metadata on how to construct the
                webapp and what its dependencies are.
                i.e. the REAL webapp deployer creates some MBean metadata
                that says it depends on the main jboss.web service (Tomcat)

                This dependency makes sure that even though the metadata for web-console.war
                was created first, the webapp is not constructed until after the webserver is running.

                Now what I think is really happening for you and why I think you're seeing a problem
                is that you have one of two problems:

                1) The webapp (metadata) you are creating is missing a dependency
                so the services are being constructed in the wrong order.

                2) You are trying to create or access the service in the deployer processing which
                you should not be doing.

                Finally (and this is not recommended although Ales hinted at in a kind of hacky way)
                you can actually make a (sub-)deployment depend on a service.
                i.e. deployments can have dependencies even at the deployer stage
                The reason this exists is to do classloading dependencies since the later
                REAL deployers need to examine classes to create metadata and also
                need to redeploy applications (reexamine classes) when dependent classes change.

                So if you really want to (not recommended)
                make your war subdeployment run after jbossweb
                The only way to do this currently is programmatically, i.e. you
                do DeploymentUnit.getDependencyInfo().addIDependOn(...)
                where the DependencyItem would say that this deployment cannot move
                to the REAL stage until the jboss.web MBean reaches the INSTALLED stage.

                NOTE: Since deployments as processed as "all or nothing" through the stages
                this would actually mean your whole sar doesn't reach the REAL stage
                until jboss.web is INSTALLED

                • 20. Re: SAR Deployment Deployers Ordering

                  So now for the reset. Which of the following mistakes is true? :-)

                  "adrian@jboss.org" wrote:

                  1) The webapp (metadata) you are creating is missing a dependency
                  so the services are being constructed in the wrong order.

                  2) You are trying to create or access the service in the deployer processing which
                  you should not be doing.


                  • 21. Re: SAR Deployment Deployers Ordering
                    ropalka

                     

                    "adrian@jboss.org" wrote:
                    So now for the reset. Which of the following mistakes is true? :-)

                    "adrian@jboss.org" wrote:

                    1) The webapp (metadata) you are creating is missing a dependency
                    so the services are being constructed in the wrong order.

                    2) You are trying to create or access the service in the deployer processing which
                    you should not be doing.

                    Welcome to the conversation Adrian ;)
                    The 2) is my problem.


                    • 22. Re: SAR Deployment Deployers Ordering
                      ropalka

                      I introduced little classloader hack few minutes ago in our deployers layer.
                      However I'd like to do it properly. I'm working on our WS deployers at the moment trying to do better and proper integration with the JBossAS 5 deployers processing.
                      The problem of our deployers is it don't deal only with deployers metadata but also with services metadata that are e.g. configured when web app is deployed.
                      Thus I need to identify what we can do in the deployers chain, and what we will need to move to upper processing layers.

                      • 23. Re: SAR Deployment Deployers Ordering
                        ropalka

                         

                        "richard.opalka@jboss.com" wrote:

                        The problem of our deployers is it don't deal only with deployers metadata but also with services metadata that are e.g. configured when web app is deployed.

                        To clarify my problem here's one example. We have two deployers registered for POJO webservices deployments which order in deployers chain is important:

                        WebServicesDeployerPreJSE < WarDeployer
                        WarDeployer < WebServicesDeployerPostJSE

                        The problem is when we have .sar deployment incorporating nested war deployment (web service POJO), the WebServicesDeployerPostJSE is called before the nested war is really deployed to the real. Thus we're getting null for JBossWebMetaData ctx loader which isn't true in case we're deploying such .sar archive using hot deploy feature (JBossAS is already running). The problem is on JBossAS bootstrap when we have such .sar archive in the deploy directory.

                        • 24. Re: SAR Deployment Deployers Ordering

                           

                          "richard.opalka@jboss.com" wrote:
                          "richard.opalka@jboss.com" wrote:

                          Thus we're getting null for JBossWebMetaData ctx loader which isn't true in case we're deploying such .sar archive using hot deploy feature (JBossAS is already running). The problem is on JBossAS bootstrap when we have such .sar archive in the deploy directory.



                          I don't see a ctx loader on JBossWebMetaData?
                          That doesn't make any sense.

                          But it sounds like your real problem is that you just want the classloader for the webapp?
                          That's obtainable just by doing DeploymentUnit.getClassLoader()

                          From AbstractWarDeployment::start()
                          which obviously doesn't get invoked until the MBean has its dependencies satisfied
                          (i.e. jbossweb is running)
                           ClassLoader warLoader = unit.getClassLoader();
                           thread.setContextClassLoader(warLoader);
                          
                          <snip/>
                          
                           webApp = new WebApplication(metaData);
                           webApp.setClassLoader(warLoader);
                          


                          • 25. Re: SAR Deployment Deployers Ordering

                            In general all your processing in the deployers should just be based on metadata
                            available to deployers or configuration on the deployers.

                            You shouldn't be looking at any services.

                            e.g. suppose the war had a dependency on an ejb from some other application
                            then its not going to be started until that ejb exists regardless of when jbossweb.sar
                            gets started.

                            • 26. Re: SAR Deployment Deployers Ordering
                              ropalka

                               

                              "adrian@jboss.org" wrote:

                              I don't see a ctx loader on JBossWebMetaData?
                              That doesn't make any sense.

                              Here's our code:
                               // JSE endpoints
                               else if (dep.getAttachment(JBossWebMetaData.class) != null)
                               {
                               JBossWebMetaData webMetaData = dep.getAttachment(JBossWebMetaData.class);
                               ClassLoader classLoader = webMetaData.getContextLoader();
                               if (classLoader == null)
                               {
                               // [JBWS-2246] hack for .sar deployments incorporating web services deployments
                               classLoader = dep.getInitialClassLoader();
                               }
                               dep.setRuntimeClassLoader(classLoader);
                               }


                              "adrian@jboss.org" wrote:
                              That's obtainable just by doing DeploymentUnit.getClassLoader()

                              Yes, this is exactly what my current hack is doing.


                              • 27. Re: SAR Deployment Deployers Ordering
                                ropalka

                                 

                                "adrian@jboss.org" wrote:
                                In general all your processing in the deployers should just be based on metadata
                                available to deployers or configuration on the deployers.

                                You shouldn't be looking at any services.

                                e.g. suppose the war had a dependency on an ejb from some other application
                                then its not going to be started until that ejb exists regardless of when jbossweb.sar
                                gets started.

                                Exactly.

                                • 28. Re: SAR Deployment Deployers Ordering
                                  ropalka

                                  Cross reference JIRA issue.

                                  • 29. Re: SAR Deployment Deployers Ordering

                                     

                                    "richard.opalka@jboss.com" wrote:
                                    "adrian@jboss.org" wrote:

                                    I don't see a ctx loader on JBossWebMetaData?
                                    That doesn't make any sense.

                                    Here's our code:
                                     // JSE endpoints
                                     else if (dep.getAttachment(JBossWebMetaData.class) != null)
                                     {
                                     JBossWebMetaData webMetaData = dep.getAttachment(JBossWebMetaData.class);
                                     ClassLoader classLoader = webMetaData.getContextLoader();
                                     if (classLoader == null)
                                     {
                                     // [JBWS-2246] hack for .sar deployments incorporating web services deployments
                                     classLoader = dep.getInitialClassLoader();
                                     }
                                     dep.setRuntimeClassLoader(classLoader);
                                     }



                                    Ok I see it now (its called cxtloader :-), it is deprecated:

                                     /** The web context class loader, used to create the ws4ee service endpoint */
                                     @Deprecated
                                     private transient ClassLoader cxtLoader;
                                    


                                    It clearly doesn't belong in the metadata description.

                                    Given what it is being used for, it is not actually the same thing
                                    as the (sub-)deployment classloader.
                                    The cxtLoader is actually a wrapper for the deployment classloader
                                    that identifies the ENC.

                                    It doesn't get set until the start of the webapp in TomcatDeployment.

                                    But there's an obvious workaround. Store the JBossWebMetaData in your "dep"
                                    (whatever that is) instead of the classloader which is unknown at that point.
                                    Then what your "dep" really creates can look it up during its start() if you depend
                                    upon the webapp.

                                    This whole area needs rewriting to get rid of all these stupid hacks
                                    and useless complexity. ;-)

                                    1 2 Previous Next