Version 2

    Design Discussion


    Goals / Requirements


    • Simple Configuration file defining which “modules” should be included
      • only deploy what the user wants
      • e.g. <i-want /> ejb3, web and clustering


    • Embedded integration
    • The configuration should be:
      • easy to use (clear, domain specific)
      • documented
      • explicit (don't include all modules)


    • Get started with modularizing AS
      • clearer picture on what our dependencies are
      • stricter AS integration requirements


    • Separate user configuration from server side configuration


    • ship AS with empty deployers/ and deploy/ folders
      • get rid of the “big ball of mud”


    • get rid of ${common.lib} (asap)


    • reduce distribution size


    Packaging changes (AS6)


    Instead of duplicating deployments in each configuration jboss-deployments will be moved to a common location - in a structure like:




    • bin/ (not affected)
    • client/ (not affected)
    • docs/ (not affected)
    • lib/ (maybe move to system/?)
    • server/
      • ${}/ (preconfigured all, default, web, ...)
        • conf/
          • server.xml (the user configuration file)
          • no bootstrap/ any more
        • deploy/ (empty)
        • deployers/ (empty)
        • lib/ (empty)
    • system (new)
      • common-lib/ (if still needed)
            • profiles/
              • containing *-profile.xml (servers side profile configurations)
            • repository (if we want to do smth. Like that?)
              • org/jboss/**/** (local maven like artifact repository)
              • artifact.xml (explicit repository configuration)
            • static
              • static file repository (containing jboss-beans.xml)
            • templates
              • to create server configurations? Basically only containing conf/


          Types of "profiles"


          In general ProfileService defines 2 different types of profiles.


          • Scanner profile
            • the AS4/AS5 notion of scanning a folder and deploying everything in there
              • e.g. deployers/ and deploy/
          • Pre-defined profile (@see server-side configuration example)
            • A “predefined-profile” is more like a (sub-)profile and can be compared with a module, with higher level (more coarse grained) module dependencies.

            • It more or less defines:
                • a group of preconfigured deployments, which are deployed together and build a "deployment-phase"
                • a set of requirments/capabilities
                • additional management capabilities (in future)

          In gernal profile descriptors have to be self-contained, in that profiles can be combined and the result is a complete description of the capabilities and requirements. Therefore a "predefined-profile" is a module description, defining which deployments have to be deployed to provide a certain service.