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.