7 Replies Latest reply on Feb 4, 2008 12:51 PM by Ales Justin

    Deployer sequencing

    Gilles Compienne Newbie

      Hello, I am trying to understand JBoss MC and there is a thing on deployer sequencing that I don't understand:

      When JBoss MC is used in the context of JBoss AS I can see that the HackClassloaderMetaDataDeployer class is only being triggered by the deployment of "console-mgr.sar". Now I must admit I don't understand why is that happening as the HackClassloaderMetaDataDeployer does not seem to be setting any input ("setInputs") or output ("setOutput").

      When I tried to write my own deployer I was able to ensure that it was always called ("setAllInputs(true); ") but I really don't understand why HackClassloaderMetaDataDeployer behaves as it currently do...

      Thanks for your help.

      Gilles.

        • 1. Re: Deployer sequencing
          Ales Justin Master

          Behaving as what?
          Being only triggered once (which I doubt is the case) or why there are no inputs/outputs?

          • 2. Re: Deployer sequencing
            Gilles Compienne Newbie

            As far as I can see it is only triggered once (looking at the log file) for a default jboss run (includes an EJB 3 bean and a few other test deployers).

            In fact I am trying to understand the exact relationships and rules existing between the classloader that seem to be created by the structure deployers and the "DESCRIBE" and "CLASSLOADER" deployers.

            I discovered HackClassloaderMetaDataDeployer and though "That's probably a good one to start with" but then I was troubled when I realized it was only called when "console-mgr.sar" is being deployed...

            I initially though that the fact it does not set input/outputs would have meant it matches all deployments (or perhaps none)... But that does not seem to be the case...

            • 3. Re: Deployer sequencing
              Ales Justin Master

              What AS5 instance are you running?

              Did you check the HackCLMDD code?
              There are (currently) two usages.
              1) there is LoaderRepositoryConfig present in attachments
              2) we're not top level deployment unit, and there is parent CLMD present

              This deployer is always triggered.
              And all it does - applying the 2 rules from above - is add ClassLoaderMetaData.
              This CLMD is later picked by ClassLoaderDeployer (if it exists).

              Regarding 'console-mgr.sar', I guess this is the only deployment that has strict scoping defined, hence the LoaderRepositoryConfig being present.

               <loader-repository>
               jboss.console:sar=console-mgr.sar
               <loader-repository-config>
               java2ParentDelegation=true
               </loader-repository-config>
               </loader-repository>
              


              • 4. Re: Deployer sequencing
                Gilles Compienne Newbie

                Arghh... My bad. I completly forgot to notice that the "log.debug" command was after the "if" that was checking the presence of the LoaderRepositoryConfig...

                Sorry...

                But thanks for your useful help.

                Gilles.

                • 5. Re: Deployer sequencing
                  Ales Justin Master

                  Source code is your friend. ;-)

                  • 6. Re: Deployer sequencing
                    Gilles Compienne Newbie

                    But this seems to confirm that if I don't specify any input then the deployer is always called (rather than never).

                    So far I was always doing a "setAllInputs(true)" but that probably was not necessary...

                    Thanks again.

                    Gilles.

                    • 7. Re: Deployer sequencing
                      Ales Justin Master

                       

                      "gcompienne" wrote:
                      But this seems to confirm that if I don't specify any input then the deployer is always called (rather than never).

                      So far I was always doing a "setAllInputs(true)" but that probably was not necessary...

                      Inputs/outputs have only one struct usage, and that's the 'natural' order.
                      If you do your deployers correctly, they can be naturally ordered by their inputs/outputs, like dominos.

                      The second use case - if they are present in attachments - is optional. It depends on what you want to do with that info.
                      e.g Most of deployers generically check if that type of attachment is present, else just pass through.

                      But you can do what ever you like. ;-)