Version 7
Created by unknownmigrationuser on Mar 16, 2004 1:07 AM. Last modified by tobias on Jul 3, 2007 12:10 PM.

    DeploymentScanner

     

    The URLDeploymentScanner is responsible for monitoring the deploy directory for deployable components (SAR files, EAR files, WAR files, etc...) that need to be deployed and notifying the MainDeployer to do the actual deployment work.  The DeploymentScanner is configured in conf/jboss-service.xml and offers several configuration options. 

     

     

    • URLs:  A comma separated list of URL strings for the locations that should be watched for changes.  Strings that do not correspond to valid URLs are treated as file paths. Relative file paths are resolved  against the server home URL, for example, JBOSS_DIST/server/default for the default config file set. If a URL represents a file then the file is deployed and watched for subsequent updates or  removal. If a URL ends in "/" to represent a directory, then the contents of the directory are treated  as a collection of deployables and scanned for content that are to be watched for updates or removal.  The requirement that a URL end in a "/" to identify a directory follows the RFC2518 convention and  allows discrimination between collections and directories that are simply unpacked archives. The default value for the URLs attribute is deploy/ which means that any SARs, EARs, JARs,  WARs, RARs, etc. dropped into the server/default/deploy directory (for the default configuration} will be automatically deployed and watched for updates.

     

     

    • ScanPeriod: The time in milliseconds between runs of the scanner thread. The default is 5000 (5 seconds).

     

     

    • URLComparator: The class name of a java.util.Comparator implementation used to specify a deployment ordering for deployments found in a scanned directory.  The implementation must  be able to compare two java.net.URL objects passed to its compare method. The default setting is the org.jboss.deployment.DeploymentSorter class which orders based on the  deployment URL suffix. The ordering of suffixes is: "sar", "service.xml", "rar", "jar", "war", "wsr",  "ear", "zip". An an alternate implementation is the org.jboss.deployment.scanner.PrefixDeploymentSorter class. Note that from 4.0.1 on, this order is actually looked up from the MainDeployerss EnhancedSuffixOrder. This orders the URLs based on numeric prefixes. The prefix digits are  converted to an int (ignoring leading zeroes), smaller prefixes are ordered ahead of larger numbers.  Deployments that do not start with any digits will be deployed after all numbered deployments.  Deployments with the same prefix value are further sorted by the DeploymentSorter logic.

     

    • Filter: The class name of a java.io.FileFilter implementation that is used to filter the contents of scanned directories. Any file not accepted by this filter will not be deployed. The default is  org.jboss.deployment.scanner.DeploymentFilter which is an implementation that  rejects the following patterns:  "", "%", ",", ".", "_$", "", "$", "%", ".BAK", ".old", ".orig", ".rej", ".bak",  ",v", "~", ".make.state", ".nse_depinfo", "CVS", "CVS.admin", "RCS", "RCSLOG",  "SCCS", "TAGS", "core", "tags".

     

    • RecursiveSearch: This property indicates whether or not deploy subdirectories are seen to be holding deployable content. If this is false, deploy subdirectories that do not contain &145;.&146; in their name are seen to be unpackaged jars with  nested subdeployments. If true, then deploy subdirectories are just groupings of deployable content. The difference between the two views shows is related to the depth  first deployment model JBoss supports. The false setting treats directories as unpackaged jars with nested content triggers the deployment of the nested content as soon as the jar directory is deployed. The true setting simply ignores the directory and adds its content to the list of deployables and calculates the order based on the previous filter logic. The default is true. However, note that the jboss-3.2.1 release shipped with a default configuration with this set to false.

     

    Relation to nested deployments

    Please note that the settings on DeploymentScanner do not influence how the SubDeployers handle nested deployments. That means if you are using the PrefixDeploymentSorter deployments that are nested in other deployments will not be sorted by their numeric prefixes but by their alphabetical order.

     

     

    Related:

     

     

    Referenced by:

     

     

     

    9247 Views Categories: Tags: