(This article describes some improvements to the AS 5/6 ProfileService  that will not be implemented in AS 6. AS 7 will work quite differently,  so much of this content may not be relevant to AS 7. However, I've moved  the article to the AS 7 space as some of the general concepts may be  relevant to AS 7 -- Brian Stansberry 7/1/2010)

Server side profile configurations

representing the available capabilities of the server, which are used to satisfy the requirements in the user configuration, as well dependencies between profiles. This configuration is intended to be static and should not be changed by the user (if possible).

One of the main differences to the current structure is that a profile will include both the deployer and the runtime services. The only reason to create 2 profiles per framework is when deploying a deployment handled by the deployer.

A (incomplete) server side profile example:

<profiles>
     <profile-group name="jboss:profile=web">

          <alias>jboss-web</alias>
          <!---
                    resolve - meaning that this dependent profile will be included.
                    Other profiles declarations are explicit!
          -->
          <requires name="jboss:profile=web,type=core" mode="resolve" />
          <!--
               activation-callback - will include and install this profile
               when it's requirements are satisfied (e.g. clustering installed)     
               -->
          <requires name="jboss:profile=web,type=clustering"
               mode="activation-callback" />
     </profile-group>

     <profile name="jboss:profile=web,type=core">
          <file-repository group="jboss-web" />
          <virtual-deployment name="jboss.web.deployer">
               <meta-inf path="deployer" />

               <artifact groupId="org.jboss.web" artifactId="deployer" />
          </virtual-deployment>
          <virtual-deployment name="jboss.web.runtime">
               <meta-inf path="runtime" />

               <artifact groupId="org.jboss.web" artifactId="jbossweb" />
               <artifact groupId="org.jboss.web" artifactId="web-service" />
          </virtual-deployment>

          <requires name="jboss:profile=common" />
          <requires name="jboss:profile=clustering" optional=”true” />
     </profile>

     <profile name="jboss:profile=web,type=clustering">
          <file-repository group="jboss.web" />
          <virtual-deployment name="jboss.web.clustering">
               <meta-inf path="clustering" />
          </virtual-deployment>

          <requires name="jboss:profile=web,type=core" >
          <requires name="jboss:profile=clustering" />
     </profile>
</profiles>

Profile names and aliases have to be unique, so that they can be resolved.

Listing of available (server-side)profiles:

• <bootstrap />

  • replaces the current bootstrap/*.xml using a KernelDeployer

  • Make (even) bootstrap more modular

  • <file-repository group="common" /> - a relative folder in system/static/*

  • <deployment name="common-jboss-beans.xml" /> - deployment name in the 'common' folder

  • <requires name="required-profile-name" optional="false" /> explicit requirement for this profile

• <profile />

  • all other server side profiles (using VDF)

  • <file-repository group="common" /> - a relative folder in system/static/*

  • <virtual-deployment /> - virtual assembly of a deployment using a VFS AssembledDirectory

    • <meta-inf /> - uses the same relative location defined in file-repository added to "META-INF"

    • <artifact /> - referenced library in a local (mvn like) repository added to the deployments classpath

  • <requires name="required-profile-name" optional="false" /> explicit requirement for this profile

All server-side profiles are immutable (no hot-deployment). Replacing system properties and other configuration related information are not part of this description.

<bootstrap /> and <profile /> can only contain explicit requirements. Optional dependencies will affect the ordering, when this profile is included by another profile. However profile-groups can be used to create composite profiles.

• <profile-group />

  • does not contain deployments, has only dependencies

  • Since all requirements are explicit (have to be included in the user configuration file) – the profile-group should simplify which profiles can be included automatically

  • <requires name="required-profile-name" mode=”...” />

    • the default 'mode' is explicit, meaning that the profile has to be included in the user-configuration

    • mode="resolve" - include the required profile to simplify the requirements in the user-configuration

    • mode="activation-callback" - the profile will be included when it's dependencies are satisfied, otherwise it won't get deployed

      • TODO better name? – it's kind of an aspect

        • e.g. include "web-clustering" if "web" and "clustering" are included

        • e.g. include "ejb3-clustering" if "ejb3" and "clustering" are included

        • e.g. include "ejb3-webservice" if "ejb3" and "webservices" are incl.

        • e.g. include "ejb2-webservices" if "ejb2" and "webservices" are incl.

    • (TODO) We most probably need finer grained requirements/capabilities

      • Maybe on a service level, so that we can change the implementation for certain services (e.g. kind of stack configuration)

      • e.g.  that the user is able to specify which stack to include:

        • webservices-stack: web-services-jboss / web-services-apache

        • osgi-framework: osgi-jboss-native / jboss-osgi-equinox-int

      • where other profiles depend on a kind of alias
        e.g. "webservices" or "osgi"