With new Microcontainer, its Deployers and JBossXB,

it's super easy to write some custom metadata along with its matching/handling deployer.

We use different files to add to deployment information, ranging from performance benefits to easily customizable classloading metadata.

This wiki page should contain the list of them, its metadata class and the most inmportant, their usage / purpose.

jboss-scanning.xml:

Current JEE specs reduced the number of configuration files,

but they now require the container to do most of the job based on @annotations.

In order to get @annotation info, containers must scan classes.

This is often performance penalty.

In order to minimize what/where we scan, we can provide this info in this file.

<scanning xmlns="urn:jboss:scanning:1.0">
  <path name="myejbs.jar">
    <include name="com.acme.foo"/>
    <exclude name="com.acme.foo.bar"/>
  </path>
  <path name="my.war/WEB-INF/classes">
    <include name="com.acme.foo"/>
  </path>
</scanning>

jboss-classloading.xml:

Simple version.

I'll let Adrian provide more complex example. ;-)

<classloading xmlns="urn:jboss:classloading:1.0" export-all="NON_EMPTY">
   <capabilities>
      <module name="test5"/>
   </capabilities>

   <requirements>
      <module name="test2"/>
   </requirements>
</classloading>

Here's an article which explains the jboss-classloading.xml in detail http://phytodata.wordpress.com/2010/10/21/demystifying-the-jboss5-jboss-classloading-xml-file/

jboss-classloading-domain.xml

Here we configure CL domain lookup in more fine-grained way.

e.g. custom parent policy

<classloading-domain xmlns="urn:jboss:classloading-domain:1.0" name="test">
   <parent-policy>
      <before-filter>org.jboss.acme,com.redhat.acme</before-filter>
      <after-filter>org.jboss.foobar,com.redhat.foobar</after-filter>
      <description>Qwert</description>
   </parent-policy>
</classloading-domain>

jboss-translator.xml

Here we add CL translators at runtime.

It could be added to system, domain or policy -- see scope attribute.

If class already has matching method, it can also be used as translator via reflection.

e.g. instrumentation's ClassFileTransformer

<classloading-translators xmlns="urn:jboss:classloading-translators:1.0">

    <translator class="org.jboss.test.deployers.vfs.classloading.support.MockTranslator" scope="DOMAIN" />

    <translator class="org.jboss.test.deployers.vfs.classloading.support.IATranslator" method="transform" scope="POLICY" />

    <translator class="org.jboss.test.deployers.vfs.classloading.support.BableFish" method="bable" scope="SYSTEM" />

</classloading-translators>

jboss-structure.xml:

This is where we describe our deployment's structure.

e.g. what is the context's path, its metadata path, classpath, comparator, modifications

You would use this in case your deployment does not comply to the usual/spec deployments,

<structure>
    <context comparator="org.jboss.test.deployment.test.SomeDeploymentComparatorTop">
        <path name=""/>
        <metaDataPath>
         <path name="META-INF"/>
      </metaDataPath>
      <classpath>
            <path name="jar1.jar"/>
            <path name="lib-dir" suffixes=".jar"/>
        </classpath>
    </context>
    <context modification="unpack">
        <path name="sub.jar"/>
      <metaDataPath>
         <path name="META-INF"/>
      </metaDataPath>
    </context>
    <context comparator="org.jboss.test.deployment.test.SomeDeploymentComparatorX">
        <path name="x.war"/>
      <metaDataPath>
         <path name="WEB-INF"/>
      </metaDataPath>
        <classpath>
            <path name="x.war/WEB-INF/classes"/>
            <path name="x.war/WEB-INF/lib" suffixes=".jar"/>
        </classpath>
    </context>
</structure>

aliases.txt:

It's a plain txt file, each line containing new alias.

(see jboss-dependency.xml for the usage)

e.g.

my-human-readable-deployment-alias

Note: this only works on top level deployment

jboss-dependency.xml:

You can define generic dependencies of your deployment wrt other deployments or even services.

e.g. my x-app.ear should start after x-util.jar is installed

e.g. my z-app.war depends on TransactionManager bean

<dependency xmlns="urn:jboss:dependency:1.0">
  <item whenRequired="Real" dependentState="Create">TransactionManager</item>
  <item>my-human-readable-deployment-alias</item>
</dependency>

For deployments the state is DeploymentStage class, for services the state is ControllerState class.

Note: module/deployment dependency can be described in jboss-classloading.xml as well.

Note2: this can be also added to sub-deployments.

jboss-deployment.xml

You can define lazy handling of deployment's ClassLoader.

e.g. don't create ClassLoader until needed by some other deployment/bundle,

or, don't move the deployment to Real stage until some class from this deployment is loaded

<deployment xmlns="urn:jboss:deployment:1.0" required-stage="PreDescribe" lazy-resolve="true">

    <lazy-start-filter recurse="false">org.foo.bar</lazy-start-filter>
    <lazy-start-filter recurse="true">com.acme.somepackage</lazy-start-filter>

</deployment>

jboss-ignore.txt

The file should include relative paths wrt its owner (sub)deployment.
e.g. META-INF/some-custom.xml or WEB-INF/lib/ui.jar/META-INF/persistence.xml

This files will then be ignored while using matching parsing deployer.