diff --git a/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-camel-component.adoc b/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-camel-component.adoc index d7a695bfc359..b2a3e67190f6 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-camel-component.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-camel-component.adoc @@ -22,7 +22,7 @@ catalog:framework |the operation to perform using the Catalog Framework (possible values are CREATE \| UPDATE \| DELETE) |=== -===== Sending Messages to Catalog Framework Endpoint +== Sending Messages to Catalog Framework Endpoint .Catalog Framework Producer In Producer mode, the component provides the ability to supply different inputs and have the Catalog Framework perform different operations based upon the header values.   diff --git a/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-intro.adoc b/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-intro.adoc index c5afcba5d878..98308a6e5102 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-intro.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-intro.adoc @@ -45,7 +45,7 @@ The Catalog Framework then invokes <<{architecture-prefix}catalog_plugins,Catal The Catalog Framework decouples clients from service implementations and provides integration points for Catalog Plugins and convenience methods for Endpoint developers. -=== Catalog API Design +== Catalog API Design The Catalog is composed of several components and an API that connects them together. The Catalog API is central to ${branding}'s architectural qualities of extensibility and flexibility.  @@ -53,12 +53,12 @@ The Catalog API consists of Java interfaces that define Catalog functionality an These interfaces provide the ability for components to interact without a dependency on a particular underlying implementation, thus allowing the possibility of alternate implementations that can maintain interoperability and share developed components. As such, new capabilities can be developed independently, in a modular fashion, using the Catalog API interfaces and reused by other ${branding} installations. -==== Ensuring Compatibility +=== Ensuring Compatibility The Catalog API will evolve, but great care is taken to retain backwards compatibility with developed components. Compatibility is reflected in version numbers. -==== Catalog Framework Sequence Diagrams +=== Catalog Framework Sequence Diagrams Because the Catalog Framework plays a central role to Catalog functionality, it interacts with many different Catalog components. To illustrate these relationships, high-level sequence diagrams with notional class names are provided below. @@ -105,7 +105,7 @@ Note that a `CatalogProvider` must be present for any ingest requests to be succ This process is similar for updating catalog entries, with update requests calling the `update(UpdateRequest)` methods on the Endpoint, `CatalogFramework`, and Catalog Provider. Similarly, for deletion of catalog entries, the delete requests call the `delete(DeleteRequest)` methods on the `Endpoint`, `CatalogFramework`, and `CatalogProvider`. -===== Error Handling +==== Error Handling Any ingest attempts that fail inside the Catalog Framework (whether the failure comes from the Catalog Framework itself, pre-ingest plugin failures, or issues with the Catalog Provider) will be logged to a separate log file for ease of error handling. The file is located at `${home_directory}/data/log/ingest_error.log` and will log the Metacards that fail, their ID and Title name, and the stack trace associated with their failure. @@ -122,7 +122,7 @@ log:set ---- ==== -===== Query +==== Query .Query Request Data Flow [ditaa,query_request,png] @@ -163,7 +163,7 @@ Optional PreQuery and PostQuery Catalog Plugins may be invoked by the `CatalogFr If a `CatalogProvider` is not configured and no other remote Sources are configured, a fault will be returned. It is possible to have only remote Sources configured and no local `CatalogProvider` configured and be able to execute queries to specific remote Sources by specifying the site name(s) in the query request. -===== Product Caching +==== Product Caching The Catalog Framework optionally provides caching of products, so future requests to retrieve the same product will be serviced much quicker. If caching is enabled, each time a retrieve product request is received, the Catalog Framework will look in its cache (default location `${home_directory}/data/product-cache`) to see if the product has been cached locally. @@ -180,6 +180,6 @@ If the Catalog Framework is unable to retrieve the product, an error message is If the admin has enabled the *Always Cache When Canceled* option, caching of the product will occur even if the client cancels the product retrieval so that future requests will be serviced quickly. Otherwise, caching is canceled if the user cancels the product download. -===== Product Download Status +==== Product Download Status As part of the caching of products, the Catalog Framework also posts events to the OSGi notification framework. Information includes when the product download started, whether the download is retrying or failed (after the number of retrieval attempts configured for product caching has been exhausted), and when the download completes. These events are retrieved by the Search UI and presented to the user who initiated the download. diff --git a/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/standard-catalog-framework.adoc b/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/standard-catalog-framework.adoc index bf4e485c8bd1..b001e9d6a235 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/standard-catalog-framework.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/standard-catalog-framework.adoc @@ -27,11 +27,11 @@ Site information about the catalog provider and/or any federated source(s) c Site information includes the source's name, version, availability, and the list of unique content types currently stored in the source (e.g., NITF). If no local catalog provider is configured, the site information returned includes site info for the catalog framework with no content types included. -===== Installing the Standard Catalog Framework +== Installing the Standard Catalog Framework The Standard Catalog Framework is bundled as the `catalog-core-standardframework` feature and can be installed and uninstalled using the normal processes described in Configuration. -===== Configuring the Standard Catalog Framework +== Configuring the Standard Catalog Framework These are the configurable properties on the Standard Catalog Framework. @@ -150,6 +150,6 @@ See <<{reference-prefix}ddf.catalog.CatalogFrameworkImpl, Catalog Standard Frame |=== -===== Known Issues with Standard Catalog Framework +== Known Issues with Standard Catalog Framework None. diff --git a/distribution/docs/src/main/resources/content/_architectures/_data/data-intro.adoc b/distribution/docs/src/main/resources/content/_architectures/_data/data-intro.adoc index 4be8953088e4..27dda13f0662 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_data/data-intro.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_data/data-intro.adoc @@ -35,12 +35,12 @@ The primary form of this metadata is the metacard.  A `Metacard` is a container for metadata.  `CatalogProviders` accept `Metacards` as input for ingest, and `Sources` search for metadata and return matching `Results` that include `Metacards`. -=== Metacards +== Metacards A metacard is a single instance of metadata in the Catalog (an instance of a metacard type) which generally contains general information about the resource, such as the title of the resource, the resource's geo-location, the date the resource was created and/or modified, the owner or producer, and/or the security classification.  -==== Metacard Type +=== Metacard Type A metacard type indicates the attributes available for a particular metacard. It is a model used to define the attributes of a metacard, much like a schema. @@ -48,7 +48,7 @@ It is a model used to define the attributes of a metacard, much like a schema. A metacard type indicates the attributes available for a particular type of data. For example, an image may have different attributes than a PDF document, so each could be defined to have their own metacard type. -===== Default Metacard Type and Attributes +==== Default Metacard Type and Attributes Most metacards within the system are created using the default metacard type or a metacard type based on the default type. The default metacard type of the system can be programmatically retrieved by calling `ddf.catalog.data.impl.MetacardImpl.BASIC_METACARD`. @@ -72,7 +72,7 @@ Every <<{introduction-prefix}introduction_to_federation_and_sources,Source>> sho Other fields may or may not be applicable, but a unique ID must be returned by a source. ==== -===== Extensible Metacards +==== Extensible Metacards Metacard extensibility is achieved by creating a new `MetacardType` that supports attributes in addition to the required attributes listed above. @@ -98,7 +98,7 @@ All `Metacards` must return a `MetacardType` object that includes an `Attri New `MetacardType` implementations can be made by implementing the `MetacardType` interface. -==== Metacard Type Registry +=== Metacard Type Registry [WARNING] ==== @@ -138,17 +138,17 @@ Typically, new `MetacardTypes` will be registered by `CatalogProviders` or sourc Typically, Endpoints or `InputTransformers` will use the lookup functionality to access a `MetacardType` based on a parameter in the incoming metadata.  Once the appropriate `MetacardType` is discovered and obtained from the registry, the component will know how to translate incoming raw metadata into a ${branding} Metacard. -==== Attributes +=== Attributes An attribute is a single field of a metacard, an instance of an attribute type. Attributes are typically indexed for searching by a source or catalog provider. -===== Attribute Types +==== Attribute Types An attribute type indicates the attribute format of the value stored as an attribute.  It is a model for an attribute. -====== Attribute Format +===== Attribute Format An enumeration of attribute formats are available in the catalog. Only these attribute formats may be used. @@ -197,13 +197,13 @@ Only these attribute formats may be used. |=== -====== Attribute Naming Conventions +===== Attribute Naming Conventions Catalog taxonomy elements follow the naming convention of `group-or-namespace.specific-term`, except for extension fields outside of the core taxonomy. These follow the naming convention of `ext.group-or-namespace.specific-term` and must be namespaced. Nesting is not permitted. -===== Result +==== Result A single "hit" included in a query response. @@ -213,13 +213,13 @@ A result object consists of the following: * a relevance score if included. * distance in meters if included. -==== Creating Metacards +=== Creating Metacards The quickest way to create a `Metacard` is to extend or construct the `MetacardImpl` object.  `MetacardImpl` is the most commonly used and extended `Metacard` implementation in the system because it provides a convenient way for developers to retrieve and set `Attributes` without having to create a new `MetacardType` (see below). `MetacardImpl` uses `BASIC_METACARD` as its `MetacardType`.   -===== Limitations +==== Limitations A given developer does not have all the information necessary to programmatically interact with any arbitrary source.  Developers hoping to query custom fields from extensible `Metacards` of other sources cannot easily accomplish that task with the current API. @@ -230,11 +230,11 @@ The only exception to this limitation is the `Metacard.ID` field, which is req A developer can always request `Metacards` from a source for which that developer has the `Metacard.ID` value.  The developer could also perform a wildcard search on the `Metacard.ID` field if the source allows. -===== Processing Metacards +==== Processing Metacards As `Metacard` objects are created, updated, and read throughout the Catalog, care should be taken by all catalog components to interrogate the `MetacardType` to ensure that additional `Attributes` are processed accordingly. -===== Basic Types +==== Basic Types The Catalog includes definitions of several basic types all found in the `ddf.catalog.data.BasicTypes` class. diff --git a/distribution/docs/src/main/resources/content/_architectures/_eventing/eventing-intro.adoc b/distribution/docs/src/main/resources/content/_architectures/_eventing/eventing-intro.adoc index c382bcfb2d06..da0628bd8c91 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_eventing/eventing-intro.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_eventing/eventing-intro.adoc @@ -38,7 +38,7 @@ Notably, the Catalog allows event evaluation on both the previous value (if avai Eventing allows ${branding}s to receive events on operations (e.g. create, update, delete) based on particular queries or actions. Once subscribed, users will receive notifications of events such as update or create on any source. -=== Eventing Components +== Eventing Components The key components of ${branding} Eventing include: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/_plugin-template.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/_plugin-template.adoc index 71c10ee00f41..eb56652c12f9 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/_plugin-template.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/_plugin-template.adoc @@ -7,11 +7,11 @@ {description} -===== Related Components to {plugin-name} +== Related Components to {plugin-name} Replace this sentence with links to any related components, required or optional, that affect the operation of this plugin. -===== Installing the {plugin-name} +== Installing the {plugin-name} The {plugin-name} {is || is not} installed by default with a standard installation in the ${app-name} application. @@ -25,11 +25,11 @@ To install the {plugin-name} from the ${admin-console}: . Select the *Configuration* tab. . Select the *{plugin-name}*. -===== Configuring the {plugin-name} +== Configuring the {plugin-name} {configuration} -===== Usage Limitations of the {plugin-name} +== Usage Limitations of the {plugin-name} Delete header if none. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-backup-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-backup-plugin.adoc index 46b1c88cb3da..9c56d55f85c3 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-backup-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-backup-plugin.adoc @@ -13,11 +13,11 @@ The Catalog Backup Plugin is used to enable data backup of the catalog and the m Using this plugin may impact performance negatively. ==== -===== Installing the Catalog Backup Plugin +== Installing the Catalog Backup Plugin The Catalog Backup Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Catalog Backup Plugin +== Configuring the Catalog Backup Plugin To configure the Catalog Backup Plugin: @@ -28,7 +28,7 @@ To configure the Catalog Backup Plugin: See <<{reference-prefix}ddf.catalog.backup.CatalogBackupPlugin,Catalog Backup Plugin configurations>> for all possible configurations. -===== Usage Limitations of the Catalog Backup Plugin +== Usage Limitations of the Catalog Backup Plugin * May affect performance. * Must be installed prior to ingesting any content. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-policy-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-policy-plugin.adoc index 6d5d901a4799..615602db9cb4 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-policy-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/catalog-policy-plugin.adoc @@ -7,11 +7,11 @@ The Catalog Policy Plugin configures the attributes required for users to perform Create, Read, Update, and Delete operations on the catalog. -===== Installing the Catalog Policy Plugin +== Installing the Catalog Policy Plugin The Catalog Policy Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Catalog Policy Plugin +== Configuring the Catalog Policy Plugin To configure the Catalog Policy Plugin: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/checksum-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/checksum-plugin.adoc index eebce2ed3bac..b1eff5b7cc45 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/checksum-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/checksum-plugin.adoc @@ -7,10 +7,10 @@ The Checksum plugin creates a unique checksum for resources input into the system to identify updated content. -===== Installing the Checksum Plugin +== Installing the Checksum Plugin The Checksum is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Checksum Plugin +== Configuring the Checksum Plugin The Checksum Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/client-info-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/client-info-plugin.adoc index 42cd6b08c3a5..bd43b2015d81 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/client-info-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/client-info-plugin.adoc @@ -7,15 +7,15 @@ The client info plugin injects request-specific network information into request properties, such as Remote IP Address, Remote Host Name, Servlet Scheme, and Servlet Context. -===== Related Components to the Client Info Plugin +== Related Components to the Client Info Plugin * Client info filter * <<{architecture-prefix}metacard_ingest_network_plugin,Metacard Ingest Network Plugin>> -===== Installing the Client Info Plugin +== Installing the Client Info Plugin The Client Info Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Client Info Plugin +== Configuring the Client Info Plugin The Client Info Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/content-uri-access-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/content-uri-access-plugin.adoc index 8be332d7d77e..cec9067fcd81 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/content-uri-access-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/content-uri-access-plugin.adoc @@ -7,10 +7,10 @@ The Content URI Access Plugin prevents a Metacard's resource URI from being overridden by an incoming UpdateRequest. -===== Installing the Content URI Access Plugin +== Installing the Content URI Access Plugin The Content URI Access Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Content URI Access Plugin +== Configuring the Content URI Access Plugin The Content URI Access Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/event-processor.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/event-processor.adoc index 78a5559f6d2c..034390741919 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/event-processor.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/event-processor.adoc @@ -13,15 +13,15 @@ The Event Processor applies the filter criteria for each registered subscription For more information on creating subscriptions, see <<{integrating-prefix}creating_a_subscription,Creating a Subscription>>. -===== Installing the Event Processor +== Installing the Event Processor The Event Processor is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Event Processor +== Configuring the Event Processor The Event Processor has no configurable properties. -===== Usage Limitations of the Event Processor +== Usage Limitations of the Event Processor The Standard Event processor currently broadcasts federated events and should not. It should only broadcast events that were generated locally, all other events should be dropped. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/expiration-date-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/expiration-date-plugin.adoc index 2b7d23bda25e..80664ea2ce8b 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/expiration-date-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/expiration-date-plugin.adoc @@ -7,7 +7,7 @@ The Expiration Date plugin adds or updates expiration dates which can be used later for archiving old data. -===== Installing the Expiration Date Pre-Ingest Plugin +== Installing the Expiration Date Pre-Ingest Plugin The Expiration Date Pre-Ingest Plugin is not installed by default with a standard installation. To install: @@ -17,7 +17,7 @@ To install: . Select the *Configuration* tab. . Select the *Expiration Data Pre-Ingest Plugin*. -===== Configuring the Expiration Date Pre-Ingest Plugin +== Configuring the Expiration Date Pre-Ingest Plugin To configure the Expiration Date Pre-Ingest Plugin: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/filter-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/filter-plugin.adoc index 370b5b19f9da..d30ceb98f6af 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/filter-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/filter-plugin.adoc @@ -62,10 +62,10 @@ Each of these user (or subject) claims will be converted to a `KeyValuePermissio These permission objects will be implied against the permission object generated from the metacard record. In this particular case, the metacard might be allowed if the policy is configured appropriately because all of the permissions line up correctly. -===== Installing the Filter Plugin +== Installing the Filter Plugin The Filter Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Filter Plugin +== Configuring the Filter Plugin The Filter Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/geocoder-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/geocoder-plugin.adoc index 0f3266b2a2d5..0a81e1c82083 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/geocoder-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/geocoder-plugin.adoc @@ -15,11 +15,11 @@ The GeoCoder relies on either the WebService or <<{reference-prefix}offline_gaze For a polygon or polygons, this plugin takes the center point of the bounding box to assign the country code. ==== -===== Installing the GeoCoder Plugin +== Installing the GeoCoder Plugin The GeoCoder Plugin is installed by default with the ${ddf-spatial} application, when the WebService or Offline Gazetteer is started. -===== Configuring the GeoCoder Plugin +== Configuring the GeoCoder Plugin To configure the GeoCoder Plugin: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/historian-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/historian-plugin.adoc index 8ffd284e03cd..affd489b4031 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/historian-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/historian-plugin.adoc @@ -7,10 +7,10 @@ The Historian Policy Plugin protects metacard history from being edited or deleted by users without the history role (a `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role` of `system-history`). -===== Installing the Historian Policy Plugin +== Installing the Historian Policy Plugin The Historian is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Historian Policy Plugin +== Configuring the Historian Policy Plugin The Historian Policy Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/jpeg2000-thumbnail-converter.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/jpeg2000-thumbnail-converter.adoc index a181d48abfb6..a7ad305b6d94 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/jpeg2000-thumbnail-converter.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/jpeg2000-thumbnail-converter.adoc @@ -7,10 +7,10 @@ The JPEG2000 Thumbnail converter creates thumbnails from images ingested in jpeg2000 format. -===== Installing the JPEG2000 Thumbnail Converter +== Installing the JPEG2000 Thumbnail Converter The JPEG2000 Thumbnail Converter is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the JPEG2000 Thumbnail Converter +== Configuring the JPEG2000 Thumbnail Converter The JPEG2000 Thumbnail Converter has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-attribute-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-attribute-plugin.adoc index 72b72d54e684..aee22ad7867d 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-attribute-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-attribute-plugin.adoc @@ -36,7 +36,7 @@ The policy plugin could also be used to rename attributes. If there is only one and the combination policy is union, then the attribute's values are effectively renamed to the destination attribute. -===== Installing the Metacard Attribute Security Policy Plugin +== Installing the Metacard Attribute Security Policy Plugin The Metacard Attribute Security Policy Plugin is installed by default with a standard installation in the ${ddf-catalog} application. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-filestorage.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-filestorage.adoc index b52850de23c3..af1de3ce8d85 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-filestorage.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-filestorage.adoc @@ -7,7 +7,7 @@ The Metacard Backup File Storage Provider is a storage provider that will store backed-up metacards in a specified file system location. -===== Installing the Metacard Backup File Storage Provider +== Installing the Metacard Backup File Storage Provider To install the Metacard Backup File Storage Provider @@ -16,7 +16,7 @@ To install the Metacard Backup File Storage Provider . Select the *Features* tab. . Install the `catalog-metacard-backup-filestorage` feature. -===== Configuring the Metacard Backup File Storage Provider +== Configuring the Metacard Backup File Storage Provider To configure the Metacard Backup File Storage Provider diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-s3-storage.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-s3-storage.adoc index b7c78dbc3c32..9f5e3fbf4889 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-s3-storage.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-s3-storage.adoc @@ -7,7 +7,7 @@ The Metacard Backup S3 Storage Provider is a storage provider that will store backed up metacards in the specified S3 bucket and key. -===== Installing the Metacard S3 File Storage Provider +== Installing the Metacard S3 File Storage Provider To install the Metacard Backup File Storage Provider @@ -15,7 +15,7 @@ To install the Metacard Backup File Storage Provider . Select the *Features* tab. . Install the `catalog-metacard-backup-s3storage` feature. -===== Configuring the Metacard S3 File Storage Provider +== Configuring the Metacard S3 File Storage Provider To configure the Metacard Backup S3 Storage Provider: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-groomer.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-groomer.adoc index cda425a8949d..81c8b389c672 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-groomer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-groomer.adoc @@ -21,10 +21,10 @@ In an `UpdateRequest`, the same operations are performed as a `CreateRequest`, e * If no value is provided for `Metacard.ID` in the new metacard, it will be set using the `UpdateRequest` ID if applicable. -===== Installing the Metacard Groomer +== Installing the Metacard Groomer The Metacard Groomer is included in the `catalog-core-plugins` feature. It is not recommended to uninstall this feature. -===== Configuring the Metacard Groomer +== Configuring the Metacard Groomer The Metacard Groomer has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-resource-size-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-resource-size-plugin.adoc index 495dddeb2217..d937d6a59b79 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-resource-size-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-resource-size-plugin.adoc @@ -9,10 +9,10 @@ This post-query plugin updates the resource size attribute of each metacard in t Use this post-query plugin as a convenience to return query results with accurate resource sizes for cached products.  -===== Installing the Metacard Resource Size Plugin +== Installing the Metacard Resource Size Plugin The Metacard Resource Size Plugin is installed by default with a standard installation. -===== Configuring the Metacard Resource Size Plugin +== Configuring the Metacard Resource Size Plugin The Metacard Resource Size Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-filter.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-filter.adoc index 439f41493f9a..1262d7c420ba 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-filter.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-filter.adoc @@ -7,10 +7,10 @@ The Metacard Validity Filter Plugin determines whether metacards with validation errors or warnings are filtered from query results. -===== Related Components to the Metacard Validity Filter Plugin +== Related Components to the Metacard Validity Filter Plugin * <<_metacard_validity_marker,Metacard Validity Marker>>. -===== Installing the Metacard Validity Filter Plugin +== Installing the Metacard Validity Filter Plugin The Metacard Validity Filter Plugin is installed by default with a standard installation in the ${ddf-catalog} application. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-marker.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-marker.adoc index cbc92279978b..7238d05c855c 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-marker.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-validity-marker.adoc @@ -16,18 +16,18 @@ If an ingest did not fail, there are no errors in the ingest log, but the expect verify either that the ingested data is valid or that the <<_metacard_validity_filter_plugin,Metacard Validity Filter Plugin>> is configured to show warnings and/or errors. ==== -===== Related Components to the Metacard Validity Marker +== Related Components to the Metacard Validity Marker * <<_metacard_validity_filter_plugin,Metacard Validity Filter Plugin>>. -===== Installing Metacard Validity Marker +== Installing Metacard Validity Marker This plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring Metacard Validity Marker +== Configuring Metacard Validity Marker See <<{reference-prefix}ddf.catalog.metacard.validation.MetacardValidityMarkerPlugin,Metacard Validity Marker Plugin configurations>> for all possible configurations. -===== Using Metacard Validity Marker +== Using Metacard Validity Marker Use this pre-ingest plugin to validate metacards against metacard validators, which can check schemas, schematron, or any other logic.  diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacardingest-network.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacardingest-network.adoc index 895e65e9be2b..e2db700d92b3 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/metacardingest-network.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/metacardingest-network.adoc @@ -9,15 +9,15 @@ The Metacard Ingest Network Plugin allows the conditional insertion of new attri For the extent of this section, a 'rule' will refer to a configured, single instance of this plugin. -===== Related Components to the Metacard Ingest Network Plugin +== Related Components to the Metacard Ingest Network Plugin * <<_client_info_plugin,Client Info Plugin>> -===== Installing the Metacard Ingest Network Plugin +== Installing the Metacard Ingest Network Plugin The Metacard Ingest Network Plugin is installed by default during a standard installation in the ${ddf-catalog} application. -===== Configuring the Metacard Ingest Network Plugin +== Configuring the Metacard Ingest Network Plugin To configure the Metacard Ingest Network Plugin: @@ -58,7 +58,7 @@ security.access-groups = SJ202, SR 101, JS2201 ---- -====== Useful Attributes +=== Useful Attributes The following table provides some useful attributes that may commonly be set by this plugin: @@ -91,7 +91,7 @@ The following table provides some useful attributes that may commonly be set by |yes |=== -===== Usage Limitations of the Metacard Ingest Network Plugin +== Usage Limitations of the Metacard Ingest Network Plugin * This plugin only works for ingest (create requests) performed over a network; data ingested via command line does not get processed by this plugin. * Any attribute that is already set on the metacard will not be overwritten by the plugin. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/operation-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/operation-plugin.adoc index 7c098b690d0e..ea9b517ae702 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/operation-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/operation-plugin.adoc @@ -7,10 +7,10 @@ The operation plugin validates the subject's security attributes to ensure they are adequate to perform the operation. -===== Installing the Operation Plugin +== Installing the Operation Plugin The Operation Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Operation Plugin +== Configuring the Operation Plugin The Operation Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/plugins-intro.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/plugins-intro.adoc index d43b59e8ecba..09fdfda5cdab 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/plugins-intro.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/plugins-intro.adoc @@ -34,7 +34,7 @@ Plugins are additional tools to use to add additional business logic at certain The Catalog Framework calls Catalog Plugins to process requests and responses as they enter and leave the Framework.  -=== Types of Plugins +== Types of Plugins Plugins can be designed to run before or after certain processes. They are often used for validation, optimization, or logging. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/point-of-contact-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/point-of-contact-plugin.adoc index 7a53ca250d1c..3089ebe23759 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/point-of-contact-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/point-of-contact-plugin.adoc @@ -9,14 +9,14 @@ The Point of Contact Policy Plugin is a PreUpdate plugin that will check if the If it does, then it adds a policy to that metacard’s policy map that cannot be implied. This will deny such an update request, which essentially makes the point-of-contact attribute read-only. -===== Related Components to Point of Contact Policy Plugin +== Related Components to Point of Contact Policy Plugin <<_point_of_contact_policy_plugin,Point of Contact Update Plugin>> -===== Installing the Point of Contact Policy Plugin +== Installing the Point of Contact Policy Plugin The Point of Contact Policy Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Point of Contact Policy Plugin +== Configuring the Point of Contact Policy Plugin The Point of Contact Policy Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/processing-post-ingest-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/processing-post-ingest-plugin.adoc index 40236305e1e6..2cf57c34a456 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/processing-post-ingest-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/processing-post-ingest-plugin.adoc @@ -7,14 +7,14 @@ The Processing Post Ingest Plugin is responsible for submitting catalog Create, Update, and Delete (CUD) requests to the <<_asynchronous_processing_framework,Processing Framework>>. -===== Related Components to Processing Post-Ingest Plugin +== Related Components to Processing Post-Ingest Plugin None. -===== Installing the Processing Post-Ingest Plugin +== Installing the Processing Post-Ingest Plugin The Processing Post-Ingest Plugin is not installed by default with a standard installation, but is installed by default when the in-memory Processing Framework is installed. -===== Configuring the Processing Post-Ingest Plugin +== Configuring the Processing Post-Ingest Plugin The Processing Post-Ingest Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/resource-uri-policy-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/resource-uri-policy-plugin.adoc index 6376961e41c8..6779499ee736 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/resource-uri-policy-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/resource-uri-policy-plugin.adoc @@ -7,11 +7,11 @@ The Resource URI Policy Plugin configures the attributes required for users to set the resource URI when creating a metacard or alter the resource URI when updating an existing metacard in the catalog. -===== Installing the Resource URI Policy Plugin +== Installing the Resource URI Policy Plugin The Resource URI Policy Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Resource URI Policy Plugin +== Configuring the Resource URI Policy Plugin To configure the Resource URI Policy Plugin: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/security-audit-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/security-audit-plugin.adoc index 54f8f994c2fb..4fc69ef47ad8 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/security-audit-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/security-audit-plugin.adoc @@ -8,6 +8,6 @@ The Security Audit Plugin is used to allow the auditing of specific metacard attributes. Any time a metacard attribute listed in the configuration is updated, a log will be generated in the security log. -===== Installing the Security Audit Plugin +== Installing the Security Audit Plugin The Security Audit Plugin is installed by default with a standard installation in the ${ddf-catalog} application. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/security-logging-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/security-logging-plugin.adoc index 8fb256d15360..94a228d0584d 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/security-logging-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/security-logging-plugin.adoc @@ -7,10 +7,10 @@ The Security Logging Plugin logs operations to the security log. -===== Installing Security Logging Plugin +== Installing Security Logging Plugin The Security Logging Plugin is installed by default in a standard installation in the ${ddf-security} application. -===== Enhancing the Security Log +== Enhancing the Security Log The security log contains attributes related to the subject acting on the system. To add additional attributes related to the subject to the logs, append the attribute's key to the comma separated values assigned to `security.logger.extra_attributes` in `/etc/custom.system.properties`. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/security-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/security-plugin.adoc index 50f70f054c56..407ae931cb5c 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/security-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/security-plugin.adoc @@ -7,10 +7,10 @@ The Security Plugin identifies the subject for an operation. -===== Installing the Security Plugin +== Installing the Security Plugin The Security Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Security Plugin +== Configuring the Security Plugin The Security Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/tags-filter-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/tags-filter-plugin.adoc index 369dc52e002a..42a6826dd3c1 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/tags-filter-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/tags-filter-plugin.adoc @@ -8,15 +8,15 @@ The Tags Filter Plugin updates queries without filters for tags, and adds a default tag of `resource`. For backwards compatibility, a filter will also be added to include metacards without any tags attribute. -===== Related Components to Tags Filter Plugin +== Related Components to Tags Filter Plugin None. -===== Installing the Tags Filter Plugin +== Installing the Tags Filter Plugin The Tags Filter Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Tags Filter Plugin +== Configuring the Tags Filter Plugin The Tags Filter Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/video-thumbnail-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/video-thumbnail-plugin.adoc index fcced101fb70..a6901615d9b5 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/video-thumbnail-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/video-thumbnail-plugin.adoc @@ -16,11 +16,11 @@ This plugin uses a custom 32-bit LGPL build of https://ffmpeg.org/[FFmpeg] (a vi Prebuilt FFmpeg binaries are provided for Linux, Mac, and Windows only. ==== -===== Installing the Video Thumbnail Plugin +== Installing the Video Thumbnail Plugin The Video Thumbnail Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Video Thumbnail Plugin +== Configuring the Video Thumbnail Plugin To configure the Video Thumbnail Plugin: diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-access-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-access-plugin.adoc index 43da20a2976d..6c654f2ceed6 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-access-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-access-plugin.adoc @@ -7,16 +7,16 @@ The Workspace Access Plugin prevents non-owner users from changing workspace permissions. -===== Related Components to The Workspace Access Plugin +== Related Components to The Workspace Access Plugin * <<_workspace_sharing_policy_plugin,Workspace Sharing Policy Plugin>>. * <<_workspace_pre_ingest_plugin,Workspace Pre-Ingest Plugin>>. * Workspace Extension. -===== Installing the Workspace Access Plugin +== Installing the Workspace Access Plugin The Workspace Access Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Workspace Access Plugin +== Configuring the Workspace Access Plugin The Workspace Access Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-pre-ingest-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-pre-ingest-plugin.adoc index 8c746f66f968..843be56c87d1 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-pre-ingest-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-pre-ingest-plugin.adoc @@ -7,16 +7,16 @@ The Workspace Pre-Ingest Plugin verifies that a workspace has an associated email to enable sharing and assigns that email as "owner". -===== Related Components to The Workspace Pre-Ingest Plugin +== Related Components to The Workspace Pre-Ingest Plugin * <<_workspace_sharing_policy_plugin,Workspace Sharing Policy Plugin>>. * <<_workspace_access_plugin,Workspace Access Plugin>>. * Workspace Extension. -===== Installing the Workspace Pre-Ingest Plugin +== Installing the Workspace Pre-Ingest Plugin The Workspace Pre-Ingest Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Workspace Pre-Ingest Plugin +== Configuring the Workspace Pre-Ingest Plugin The Workspace Pre-Ingest Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-sharing-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-sharing-plugin.adoc index 0dce04ae563f..7b1e046ebddc 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-sharing-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/workspace-sharing-plugin.adoc @@ -7,16 +7,16 @@ The Workspace Sharing Policy Plugin collects attributes for a workspace to identify the appropriate policy to apply to allow sharing. -===== Related Components to The Workspace Sharing Policy Plugin +== Related Components to The Workspace Sharing Policy Plugin * <<_workspace_access_plugin,Workspace Access Plugin>>. * <<_workspace_pre_ingest_plugin,Workspace Pre-Ingest Plugin>>. * Workspace Extension. -===== Installing the Workspace Sharing Policy Plugin +== Installing the Workspace Sharing Policy Plugin The Workspace Sharing Policy Plugin is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Workspace Sharing Policy Plugin +== Configuring the Workspace Sharing Policy Plugin The Workspace Sharing Policy Plugin has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_plugins/xml-attribute-plugin.adoc b/distribution/docs/src/main/resources/content/_architectures/_plugins/xml-attribute-plugin.adoc index 265000463a00..0bbd061cd669 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_plugins/xml-attribute-plugin.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_plugins/xml-attribute-plugin.adoc @@ -9,7 +9,7 @@ The XML Attribute Security Policy Plugin parses XML metadata contained within a The configuration for the plugin contains one field for setting the XML elements that will be parsed for security attributes and the other two configurations contain the XML attributes that will be pulled off of those elements. The *Security Attributes (union)* field will compute the union of values for each attribute defined and the *Security Attributes (intersection)* field will compute the intersection of values for each attribute defined. -===== Installing the XML Attribute Security Policy Plugin +== Installing the XML Attribute Security Policy Plugin The XML Attribute Security Policy Plugin is installed by default with a standard installation in the ${ddf-security} application. diff --git a/distribution/docs/src/main/resources/content/_architectures/_queries/filterbuilder-api.adoc b/distribution/docs/src/main/resources/content/_architectures/_queries/filterbuilder-api.adoc index 45d98ac3eda0..45c01e11b036 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_queries/filterbuilder-api.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_queries/filterbuilder-api.adoc @@ -17,7 +17,7 @@ The fluent API is best accessed using an IDE that supports code-completion. For additional details, refer to the [Catalog API Javadoc]. ==== -==== Boolean Operators +== Boolean Operators Filters use a number of boolean operators. @@ -27,7 +27,7 @@ Filters use a number of boolean operators. `FilterBuilder.not(Filter filter)`:: creates a new Filter that requires the provided Filter must not match (Boolean NOT). -==== Attribute +== Attribute Filters can be based on specific attributes. diff --git a/distribution/docs/src/main/resources/content/_architectures/_resources/retrieving-resources.adoc b/distribution/docs/src/main/resources/content/_architectures/_resources/retrieving-resources.adoc index 4822c3d07fca..1a8de0d35d39 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_resources/retrieving-resources.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_resources/retrieving-resources.adoc @@ -39,7 +39,7 @@ As an example, one `ResourceReader` may know how to handle file-based URIs wit The `ResourceReader` or `Source` is responsible for locating the resource, reading its bytes, adding the binary data to a `Resource` implementation, then returning that `Resource` in a `ResourceResponse`.  The `ResourceReader` or `Source` is also responsible for determining the ``Resource``'s name and mime type, which it sends back in the `Resource` implementation. -===== BinaryContent +== BinaryContent `BinaryContent` is an object used as a container to store translated or transformed ${branding} components.  `Resource` extends `BinaryContent` and includes a `getName` method.  diff --git a/distribution/docs/src/main/resources/content/_architectures/_resources/url-resource-reader.adoc b/distribution/docs/src/main/resources/content/_architectures/_resources/url-resource-reader.adoc index 6ce406b839a4..87ffa2e5081c 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_resources/url-resource-reader.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_resources/url-resource-reader.adoc @@ -16,11 +16,11 @@ It is downloaded from the product cache which bypasses the `URLResourceReader`. For example, if path `/my/valid/path` is configured in the ``URLResourceReader``'s `rootResourceDirectories` and one downloads the product with resource-uri `file:///my/valid/path/product.txt` and then one removes `/my/valid/path` from the ``URLResourceReader``'s `rootResourceDirectories` configuration, the product will still be accessible via the product cache. ==== -===== Installing the URL Resource Reader +== Installing the URL Resource Reader The `URLResourceReader` is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring Permissions for the URL Resource Reader +== Configuring Permissions for the URL Resource Reader Configuring the URL Resource Reader to retrieve files requires adding Security Manager read permission entries for the directory containing the resources. To add the correct permission entries, edit the file ${home_directory}/security/configurations.policy. In the URL Resource Reader section of the file, add two new permission for each top-level directory that the Resource Reader needs to access. The Resource Reader needs one permission to read the directory and another to read its contents. @@ -38,7 +38,7 @@ permission java.io.FilePermission "", "read"; Trailing slashes after have no effect on the permissions granted. For example, adding a permission for "${/}test${/}path" and "${/}test${/}path${/}" are equivalent. The recursive forms "${/}test${/}path${/}-", and "${/}test${/}path${/}${/}-" are also equivalent. -===== Configuring the URL Resource Reader +== Configuring the URL Resource Reader Configure the URL Resource Reader from the ${admin-console}. @@ -49,7 +49,7 @@ Configure the URL Resource Reader from the ${admin-console}. See <<{reference-prefix}ddf.catalog.resource.impl.URLResourceReader,URL Resource Reader configurations>> for all possible configurations. -==== Using the URL Resource Reader +== Using the URL Resource Reader `URLResourceReader` will be used by the Catalog Framework to obtain a resource whose metacard is cataloged in the local data store. This particular `ResourceReader` will be chosen by the `CatalogFramework` if the requested resource's URL has a protocol of `http`, `https`, or `file`.   diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/atom-queryresp-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/atom-queryresp-xformer.adoc index 142478fc9d62..843395ccc2d9 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/atom-queryresp-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/atom-queryresp-xformer.adoc @@ -8,15 +8,15 @@ The Atom Query Response Transformer transforms a query response into an http://tools.ietf.org/html/rfc4287[Atom 1.0] feed. The Atom transformer maps a `QueryResponse` object as described in the Query Result Mapping. -===== Installing the Atom Query Response Transformer +== Installing the Atom Query Response Transformer The Atom Query Response Transformer is installed by default with a standard installation. -===== Configuring the Atom Query Response Transformer +== Configuring the Atom Query Response Transformer The Atom Query Response Transformer has no configurable properties. -===== Using the Atom Query Response Transformer +== Using the Atom Query Response Transformer Use this transformer when Atom is the preferred medium of communicating information, such as for feed readers or federation. An integrator could use this with an endpoint to transform query responses into an Atom feed. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/csw-queryresp-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/csw-queryresp-xformer.adoc index 795b7e7c8d19..3af506d4fb99 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/csw-queryresp-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/csw-queryresp-xformer.adoc @@ -7,11 +7,11 @@ The CSW Query Response Transformer transforms a query response into a http://www.opengeospatial.org/standards/cat[CSW-formatted] document. -===== Installing the CSW Query Response Transformer +== Installing the CSW Query Response Transformer The CSW Query Response Transformer is installed by default with a standard installation in the ${ddf-spatial} application. -===== Configuring the CSW Query Response Transformer +== Configuring the CSW Query Response Transformer The CSW Query Response Transformer has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/custom-mime-type-resolver.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/custom-mime-type-resolver.adoc index 6ccd1123a0c5..47ab8a80b721 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/custom-mime-type-resolver.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/custom-mime-type-resolver.adoc @@ -26,14 +26,14 @@ These are mime types not supported by the default `TikaMimeTypeResolver`. As a `MimeTypeResolver`, the Custom Mime Type Resolver will provide methods to map the file extension to the corresponding mime type, and vice versa. -===== Installing the Custom Mime Type Resolver +== Installing the Custom Mime Type Resolver One Custom Mime Type Resolver is configured and installed for the `image/nitf` mime type. This custom resolver is bundled in the `mime-core-app` application and is part of the `mime-core` feature. Additional Custom Mime Type Resolvers can be added for other custom mime types. -====== Configuring the Custom Mime Type Resolver +== Configuring the Custom Mime Type Resolver The configurable properties for the Custom Mime Type Resolver are accessed from the *MIME Custom Types* configuration in the ${admin-console}. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/ddf-mime-type-mapper.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/ddf-mime-type-mapper.adoc index 368fbb80465b..509fabb43bec 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/ddf-mime-type-mapper.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/ddf-mime-type-mapper.adoc @@ -7,11 +7,11 @@ The ${ddf-branding} Mime Type Mapper is the core implementation of the ${ddf-branding} Mime API. It provides access to all `MimeTypeResolvers` within ${branding}, which provide mapping of mime types to file extensions and file extensions to mime types. -===== Installing the ${ddf-branding} Mime Type Mapper +== Installing the ${ddf-branding} Mime Type Mapper The ${ddf-branding} Mime Type Mapper is installed by default with a standard installation in the ${ddf-platform} application. -===== Configuring ${ddf-branding} Mime Type Mapper +== Configuring ${ddf-branding} Mime Type Mapper The ${ddf-branding} Mime Type Mapper has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-input-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-input-xformer.adoc index b1bbd778f88a..a5d7c851220a 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-input-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-input-xformer.adoc @@ -18,15 +18,15 @@ The GeoJSON input transformer is responsible for translating GeoJSON into a Cata |application/json |=== -===== Installing the GeoJSON Input Transformer +== Installing the GeoJSON Input Transformer The GeoJSON Input Transformer is installed by default with a standard installation. -===== Configuring the GeoJSON Input Transformer +== Configuring the GeoJSON Input Transformer The GeoJSON Input Transformer has no configurable properties. -===== Using the GeoJSON Input Transformer +== Using the GeoJSON Input Transformer Using the REST Endpoint, for example, HTTP POST a GeoJSON metacard to the Catalog. Once the REST Endpoint receives the GeoJSON Metacard, it is converted to a Catalog metacard. @@ -36,7 +36,7 @@ Once the REST Endpoint receives the GeoJSON Metacard, it is converted to a Catal curl -X POST -i -H "Content-Type: application/json" -d "${at-symbol}metacard.json" ${secure_url}/services/catalog ---- -===== Conversion to a Metacard +== Conversion to a Metacard A http://geojson.org/geojson-spec.html#geojson-objects[GeoJSON object] consists of a single JSON object. This can be a geometry, a feature, or a `FeatureCollection`. @@ -92,7 +92,7 @@ XML must be properly escaped, such as what is proper for normal JSON. Currently, only *Required Attributes* are recognized in the properties. -====== Metacard Extensibility +=== Metacard Extensibility GeoJSON supports custom, extensible properties on the incoming GeoJSON using ${branding}'s extensible metacard support. To have those customized attributes understood by the system, a corresponding `MetacardType` must be registered with the `MetacardTypeRegistry`. @@ -131,7 +131,7 @@ When the GeoJSON Input Transformer gets GeoJSON with the `MetacardType` specifie If no `MetacardType` is specified, the GeoJSON Input Transformer will assume the default `MetacardType`. If an unregistered `MetacardType` is specified, an exception will be returned to the client indicating that the `MetacardType` was not found. -===== Usage Limitations of the GeoJSON Input Transformer +== Usage Limitations of the GeoJSON Input Transformer The GeoJSON Input Transformer does not handle multiple geometries. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-metacard-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-metacard-xformer.adoc index acad8d082f4a..142b0b540750 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-metacard-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-metacard-xformer.adoc @@ -7,7 +7,7 @@ GeoJSON Metacard Transformer translates a metacard into GeoJSON. -===== Installing the GeoJSON Metacard Transformer +== Installing the GeoJSON Metacard Transformer The GeoJSON Metacard Transformer is not installed by default with a standard installation. @@ -18,11 +18,11 @@ To install: . Select the *Features* tab. . Install the `catalog-transformer-json` feature. -===== Configuring the GeoJSON Metacard Transformer +== Configuring the GeoJSON Metacard Transformer The GeoJSON Metacard Transformer has no configurable properties. -===== Using the GeoJSON Metacard Transformer +== Using the GeoJSON Metacard Transformer The GeoJSON Metacard Transformer can be used programmatically by requesting a `MetacardTransformer` with the id `geojson`. It can also be used within the REST Endpoint by providing the transform option as `geojson`. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-queryresp-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-queryresp-xformer.adoc index 4a36724a59f3..73e8906bf1c3 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-queryresp-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/geojson-queryresp-xformer.adoc @@ -7,11 +7,11 @@ The GeoJSON Query Response Transformer translates a query response into a GeoJSON-formatted document. -===== Installing the GeoJSON Query Response Transformer +== Installing the GeoJSON Query Response Transformer The GeoJSON Query Response Transformer is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the GeoJSON Query Response Transformer +== Configuring the GeoJSON Query Response Transformer The GeoJSON Query Response Transformer has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-metacard-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-metacard-xformer.adoc index d1c42f85a1f0..e491ed7378cc 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-metacard-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-metacard-xformer.adoc @@ -9,15 +9,15 @@ The KML Metacard Transformer is responsible for translating a metacard into a KM The KML will contain an HTML description that will display in the pop-up bubble in Google Earth. The HTML contains links to the full metadata view as well as the resource. -===== Installing the KML Metacard Transformer +== Installing the KML Metacard Transformer The KML Metacard Transformer is installed by default with a standard installation in the ${ddf-spatial} Application. -===== Configuring the KML Metacard Transformer +== Configuring the KML Metacard Transformer The KML Metacard Transformer has no configurable properties. -===== Using the KML Metacard Transformer +== Using the KML Metacard Transformer Using the REST Endpoint for example, request a metacard with the transform option set to the KML shortname. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-queryresp-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-queryresp-xformer.adoc index 3dad86e0430c..5d84eff9649e 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-queryresp-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-queryresp-xformer.adoc @@ -9,15 +9,15 @@ The KML Query Response Transformer translates a query response into a KML-format The KML will contain an HTML description for each metacard that will display in the pop-up bubble in Google Earth. The HTML contains links to the full metadata view as well as the resource. -===== Installing the KML Query Response Transformer +== Installing the KML Query Response Transformer The `spatial-kml-transformer` feature is installed by default in the ${ddf-spatial} Application. -===== Configuring the KML Query Response Transformer +== Configuring the KML Query Response Transformer The KML Query Response Transformer has no configurable properties. -===== Using the KML Query Response Transformer +== Using the KML Query Response Transformer Using the OpenSearch Endpoint, for example, query with the format option set to the KML shortname: `kml`. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-style-mapper.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-style-mapper.adoc index 2f56386550b3..e5a7705d343c 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-style-mapper.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/kml-style-mapper.adoc @@ -15,11 +15,11 @@ For more information on style URL's, refer to the https://developers.google.com/ The KML Style Mapper supports all basic and extended metacard attributes. When a style mapping is configured, the resulting transformed KML contain a `` tag pointing to that style, rather than the default KML style supplied by the `KMLTransformer`. -===== Installing the KML Style Mapper +== Installing the KML Style Mapper The KML Style Mapper is installed by default with a standard installation in the <<{reference-prefix}spatial_application_reference,${ddf-spatial} Application>> in the `spatial-kml-transformer` feature. -===== Configuring the KML Style Mapper +== Configuring the KML Style Mapper The properties below describe how to configure a style mapping. The configuration name is `Spatial KML Style Map Entry`. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/metadata-metacard-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/metadata-metacard-xformer.adoc index 7a228f21290b..5654498dfe13 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/metadata-metacard-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/metadata-metacard-xformer.adoc @@ -8,15 +8,15 @@ The Metadata Metacard Transformer returns the `Metacard.METADATA` attribute when given a metacard. The MIME Type returned is `text/xml`. -===== Installing the Metadata Metacard Transformer +== Installing the Metadata Metacard Transformer The Metadata Metacard Transformer is installed by default in a standard installation with the ${ddf-catalog} application. -===== Configuring the Metadata Metacard Transformer +== Configuring the Metadata Metacard Transformer The Metadata Metacard Transformer has no configurable properties. -===== Using the Metadata Metacard Transformer +== Using the Metadata Metacard Transformer The Metadata Metacard Transformer can be used programmatically by requesting a metacard transformer with the id `metadata`. It can also be used within the REST Endpoint by providing the transform option as `metadata`. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/pdf-input-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/pdf-input-xformer.adoc index 54667f8b0412..589942f1cfba 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/pdf-input-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/pdf-input-xformer.adoc @@ -18,11 +18,11 @@ The PDF Input Transformer is responsible for translating a PDF document into a C |=== -===== Installing the PDF Input Transformer +== Installing the PDF Input Transformer The PDF Transformer is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the PDF Input Transformer +== Configuring the PDF Input Transformer To configure the PDF Input Transformer: diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/pptx-input-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/pptx-input-xformer.adoc index 3e7e47b697a2..3ad7b1297c42 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/pptx-input-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/pptx-input-xformer.adoc @@ -20,11 +20,11 @@ The PPTX Input Transformer will take precedence over the Tika Input Transformer |application/vnd.openxmlformats-officedocument.presentationml.presentation |=== -===== Installing the PPTX Input Transformer +== Installing the PPTX Input Transformer This transformer is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the PPTX Input Transformer +== Configuring the PPTX Input Transformer The PPTX Input Transformer has no configurable properties. ''' diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/queryresp-xformer-consumer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/queryresp-xformer-consumer.adoc index ada1c51f7c4c..44bda2bf2d62 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/queryresp-xformer-consumer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/queryresp-xformer-consumer.adoc @@ -7,10 +7,10 @@ The Query Response Transformer Consumer is responsible for translating a query response into a Catalog Metacard. -===== Installing the Query Response Transformer Consumer +== Installing the Query Response Transformer Consumer The Query Response Transformer Consumer is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Query Response Transformer Consumer +== Configuring the Query Response Transformer Consumer The Query Response Transformer Consumer has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/resource-metacard-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/resource-metacard-xformer.adoc index 5e4e682b79fe..7b4c778af004 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/resource-metacard-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/resource-metacard-xformer.adoc @@ -7,15 +7,15 @@ The Resource Metacard Transformer retrieves a resource associated with a metacard. -===== Installing the Resource Metacard Transformer +== Installing the Resource Metacard Transformer The Resource Metacard Transformer is installed by default in a standard installation with the ${ddf-catalog} application as the feature `catalog-transformer-resource`. -===== Configuring the Resource Metacard Transformer +== Configuring the Resource Metacard Transformer The Resource Metacard Transformer has no configurable properties. -===== Using the Resource Metacard Transformer +== Using the Resource Metacard Transformer Endpoints or other components can retrieve an instance of the Resource Metacard Transformer using its `id` resource. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/thumbnail-metacard-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/thumbnail-metacard-xformer.adoc index 8b8b31da86cd..d12a63f59b1a 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/thumbnail-metacard-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/thumbnail-metacard-xformer.adoc @@ -7,15 +7,15 @@ The Thumbnail Metacard Transformer retrieves the thumbnail bytes of a Metacard by returning the `Metacard.THUMBNAIL` attribute value. -===== Installing the Thumbnail Metacard Transformer +== Installing the Thumbnail Metacard Transformer This transformer is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the Thumbnail Metacard Transformer +== Configuring the Thumbnail Metacard Transformer The Thumbnail Metacard Transformer has no configurable properties. -===== Using the Thumbnail Metacard Transformer +== Using the Thumbnail Metacard Transformer Endpoints or other components can retrieve an instance of the Thumbnail Metacard Transformer using its id `thumbnail`. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-input-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-input-xformer.adoc index 47cb28660770..11458299351d 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-input-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-input-xformer.adoc @@ -23,11 +23,11 @@ This allows any registered input transformers that are more specific to a docume |This basic transformer can ingest many file types. See <<{metadata-prefix}all_file_formats_supported,All Formats Supported>>. |=== -===== Installing the Tika Input Transformer +== Installing the Tika Input Transformer This transformer is installed by default with a standard installation in the ${ddf-catalog}. -===== Configuring the Tika Input Transformer +== Configuring the Tika Input Transformer The properties below describe how to configure the Tika input transformer. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-mime-type-resolver.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-mime-type-resolver.adoc index 8f86e5ac82d5..ef3ebed73bc2 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-mime-type-resolver.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/tika-mime-type-resolver.adoc @@ -13,13 +13,13 @@ This insures that any custom `MimeTypeResolvers` that may be installed will be i The `TikaMimeTypeResolver` provides the bulk of the default mime type support for ${branding}. -===== Installing the Tika Mime Type Resolver +== Installing the Tika Mime Type Resolver The `TikaMimeTypeResolver` is bundled as the `mime-tika-resolver` feature in the `mime-tika-app` application. This feature is installed by default. -====== Configuring the Tika Mime Type Resolver +== Configuring the Tika Mime Type Resolver The Tika Mime Type Resolver has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/video-input-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/video-input-xformer.adoc index 77d825f6e23a..47d83703111c 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/video-input-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/video-input-xformer.adoc @@ -29,10 +29,10 @@ a|* video/avi |=== -===== Installing the Video Input Transformer +== Installing the Video Input Transformer This transformer is installed by default with a standard installation in the ${ddf-catalog} application. -====== Configuring the Video Input Transformer +== Configuring the Video Input Transformer The Video Input Transformer has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-input-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-input-xformer.adoc index c6e34f9907cb..b6cbfa50a826 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-input-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-input-xformer.adoc @@ -17,10 +17,10 @@ The XML Input Transformer is responsible for translating an XML document into a |text/xml |=== -===== Installing the XML Input Transformer +== Installing the XML Input Transformer The XML Input Transformer is installed by default with a standard installation in the ${ddf-catalog} application. -===== Configuring the XML Input Transformer +== Configuring the XML Input Transformer The XML Input Transformer has no configurable properties. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-metacard-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-metacard-xformer.adoc index dd3f9b65be5e..17cff62c0c98 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-metacard-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-metacard-xformer.adoc @@ -8,17 +8,17 @@ The XML metacard transformer is responsible for translating a metacard into an XML-formatted document. The metacard element that is generated is an extension of `gml:AbstractFeatureType`, which makes the output of this transformer GML 3.1.1 compatible. -===== Installing the XML Metacard Transformer +== Installing the XML Metacard Transformer This transformer comes installed by default with a standard installation in the ${ddf-catalog} application. To install or uninstall manually, use the `catalog-transformer-xml` feature. -===== Configuring the XML Metacard Transformer +== Configuring the XML Metacard Transformer The XML Metacard Transformer has no configurable properties. -===== Using the XML Metacard Transformer +== Using the XML Metacard Transformer Using the REST Endpoint for example, request a metacard with the transform option set to the XML shortname. diff --git a/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-queryresp-xformer.adoc b/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-queryresp-xformer.adoc index a892466ff475..43d4f11ea8f7 100644 --- a/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-queryresp-xformer.adoc +++ b/distribution/docs/src/main/resources/content/_architectures/_transformers/xml-queryresp-xformer.adoc @@ -8,12 +8,12 @@ The XML Query Response Transformer is responsible for translating a query response into an XML-formatted document. The metacard element generated is an extension of `gml:AbstractFeatureCollectionType`, which makes the output of this transformer http://www.opengeospatial.org/projects/groups/gmldwg[GML 3.1.1] compatible. -===== Installing the XML Query Response Transformer +== Installing the XML Query Response Transformer This transformer is installed by default with a standard installation in the ${ddf-catalog} application. To uninstall, uninstall the `catalog-transformer-xml` feature. -===== Configuring the XML Query Response Transformer +== Configuring the XML Query Response Transformer To configure the XML Query Response Transformer: @@ -25,7 +25,7 @@ To configure the XML Query Response Transformer: See <<{reference-prefix}ddf.catalog.transformer.xml.XmlResponseQueueTransformer,XML Query Response Transformer configurations>> for all possible configurations. -===== Using the XML Query Response Transformer +== Using the XML Query Response Transformer Using the OpenSearch Endpoint, for example, query with the format option set to the XML shortname `xml`. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/assuring-bundles-and-apps.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/assuring-bundles-and-apps.adoc index 56f37575211a..29d9519c7e3b 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/assuring-bundles-and-apps.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/assuring-bundles-and-apps.adoc @@ -7,7 +7,7 @@ ${branding} Artifacts in the JAR file format (such as bundles or KAR files) can be signed and verified using the tools included as part of the Java Runtime Environment. -==== Prerequisites +== Prerequisites To work with Java signatures, a keystore/truststore is required. For testing or trial purposes ${branding} can sign and validate using a self-signed certificate, generated with the keytool utility. @@ -38,7 +38,7 @@ Enter key password for Re-enter new password: ---- -==== Signing a JAR/KAR +== Signing a JAR/KAR Once a keystore is available, the JAR can be signed using the `jarsigner` tool. @@ -51,7 +51,7 @@ Additional documentation on jarsigner can be found at http://docs.oracle.com/jav ~ $ jarsigner -keystore keystore.jks -keypass shield -storepass password catalog-app-2.5.1.kar selfsigned ---- -===== Verifying a JAR/KAR +=== Verifying a JAR/KAR The jarsigner utility is also used to verify a signature in a JAR-formatted file. .Using jarsigner to verify a file diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-injection.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-injection.adoc index 6a20bf145bd2..5b27a002bc33 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-injection.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-injection.adoc @@ -7,7 +7,7 @@ Attribute injections are defined attributes that will be injected into all metacard types or into specific metacard types. This capability allows metacard types to be extended with new attributes. -==== Attribute Injection Definition +== Attribute Injection Definition To define attribute injections, create a JSON file in the `${home_directory}/etc/definitions` directory. The definition file must have an `inject` key in the root object. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-type.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-type.adoc index 135f75c44309..af50f3e321bf 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-type.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/attribute-type.adoc @@ -7,7 +7,7 @@ Create custom attribute types with Attribute Type definition files. -==== Attribute Type Definition File +== Attribute Type Definition File To define Attribute Types, the definition file must have an `attributeTypes` key in the root object. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-action-components.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-action-components.adoc index 53946f1d732a..21799d2aafa7 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-action-components.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-action-components.adoc @@ -14,13 +14,13 @@ An Action Provider is required to have an ActionProvider id. The Action Provider must register itself in the OSGi Service Registry with the `${ddf-branding-lowercase}.action.ActionProvider` interface and must also have a service property value for `id`.  An action is a URL that, when invoked, provides a resource or executes intended business logic.  -==== Action Component Naming Convention +== Action Component Naming Convention For each Action, a title and description should be provided to describe what the action does. The recommended naming convention is to use the verb 'Get' when retrieving a portion of a metacard, such as the metadata or thumbnail, or when downloading a resource. The verb 'Export' or the expression 'Export as' is recommended when the metacard is being exported in a different format or presented after going some transformation. -===== Action Component Taxonomy +=== Action Component Taxonomy An Action Provider registers an `id` as a service property in the OGSi Service Registry based on the type of service or action that is provided. Regardless of implementation, if more than one Action Provider provides the same service, such as providing a URL to a thumbnail for a given metacard, they must both register under the same `id`. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-applications.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-applications.adoc index cdf9677d74da..16e143a901f4 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-applications.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-applications.adoc @@ -13,7 +13,7 @@ A KAR file is a Karaf-specific archive format (*K*araf *AR*chive). It is a jar file that contains a feature descriptor file and one or more OSGi bundle jar files. The feature descriptor file identifies a set of bundles that need to be installed, and any dependencies on other features that may need to be installed. -==== Describing Application Services +== Describing Application Services Given the modular nature of OSGi, some applications perform operations on the services themselves. In order to present, identify, and manipulate the services, they need descriptive identifying information. @@ -33,7 +33,7 @@ such as `ddf.metacards` or `ddf.platform`; while the [*component*] within a [*pr Note that `ddf` as a [*product*] is reserved for core features only and is not meant to be used during extension or integration. -==== Creating a KAR File +== Creating a KAR File The recommended method for creating a KAR file is to use the `features-maven-plugin`, which has a `create-kar` goal. This goal reads all of the features specified in the feature's descriptor file. @@ -85,7 +85,7 @@ Examples of how KAR files are created for ${branding} components can be found in The `.kar` file generated should be deployed to the application author's maven repository. The URL to the application's KAR file in this Maven repository should be the installation URL that is used. -==== Including Data Files in a KAR File +== Including Data Files in a KAR File The developer may need to include data or configuration file(s) in a KAR file. An example of this is a properties file for the JDBC connection properties of a catalog provider. @@ -97,7 +97,7 @@ Sub-directories under `src/main/resources` can be used, e.g., `etc/security`. * The Maven project's pom file should be updated to attach each `data/configuration` file as an artifact (using the `build-helper-maven-plugin`). * Add each `data/configuration` file to the KAR file using the `` tag in the KAR's `features.xml` file. -==== Installing a KAR File +== Installing a KAR File When the user downloads an application by clicking on the *Installation* link, the application's KAR file is downloaded. To install manually, the KAR file can be placed in the `${home_directory}/deploy` directory of the running ${branding} instance. ${branding} then detects that a file with a `.kar` file extension has been placed in this monitored directory, unzips the KAR file into the `${home_directory}/system` directory, and installs the bundle(s) listed in the KAR file's feature descriptor file. @@ -109,13 +109,13 @@ To install via the ${admin-console}: . Select *Save Changes* to activate, The new application can be viewed via the ${admin-console}'s Active Applications list. -===== Developing Application Configuration Modules +=== Developing Application Configuration Modules An application within ${branding} is a collection of bundles contained in a KAR file that may or may not have configurations associated with it. Plugins are used to advertise applications. These configuration module plugins are often used to add user interface elements to make the use of the ${branding} simpler and/or more intuitive. -====== Creating an Application Configuration Module +==== Creating an Application Configuration Module This example demonstrates a plugin that allows the ${branding} to use the Admin UI. @@ -160,7 +160,7 @@ public class SourcesPlugin extends AbstractApplicationPlugin { + . Create application to use this configuration. -===== Including KAR Files +=== Including KAR Files Sometimes a developer may need to include data or configuration file(s) in a KAR file. An example of this would be a properties file for the JDBC connection properties of a catalog provider. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-catalog-frameworks.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-catalog-frameworks.adoc index b962803a702a..9cee9928077c 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-catalog-frameworks.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-catalog-frameworks.adoc @@ -7,7 +7,7 @@ ${branding} and the underlying OSGi technology can serve as a robust infrastructure for developing frameworks that complement the ${ddf-catalog}. -==== Simple Catalog API Implementations +== Simple Catalog API Implementations The Catalog API implementations, which are denoted with the suffix of `Impl` on the Java file names, have multiple purposes and uses: @@ -15,7 +15,7 @@ The Catalog API implementations, which are denoted with the suffix of `Impl` o * Second, the Catalog API Implementations display the proper usage of an interface and an interface's intentions. Also, they are good code examples for future implementations. If a developer does not want to extend the simple implementations, the developer can at least have a working code reference on which to base future development. -==== Use of the Whiteboard Design Pattern +== Use of the Whiteboard Design Pattern The ${ddf-catalog} makes extensive use of the Whiteboard Design Pattern. Catalog Components are registered as services in the OSGi Service Registry, and the Catalog Framework or any other clients tracking the OSGi Service Registry are automatically notified by the OSGi Framework of additions and removals of relevant services. @@ -23,7 +23,7 @@ Catalog Components are registered as services in the OSGi Service Registry, and The Whiteboard Design Pattern is a common OSGi technique that is derived from a technical whitepaper provided by the OSGi Alliance in 2004. It is recommended to use the Whiteboard pattern over the Listener pattern in OSGi because it provides less complexity in code (both on the client and server sides), fewer deadlock possibilities than the Listener pattern, and closely models the intended usage of the OSGi framework. -==== Recommendations for Framework Development +== Recommendations for Framework Development * Provide extensibility similar to that of the ${ddf-catalog}. ** Provide a stable API with interfaces and simple implementations (refer to `http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html`). @@ -36,7 +36,7 @@ It is recommended to use the Whiteboard pattern over the Listener pattern in OSG ** CXF ** PAX Web and Jetty -==== Catalog Framework Reference +== Catalog Framework Reference The Catalog Framework can be requested from the OSGi Service Registry. @@ -46,11 +46,11 @@ The Catalog Framework can be requested from the OSGi Service Registry. ---- -===== Methods +=== Methods The `CatalogFramework` provides convenient methods to transform `Metacards` and `QueryResponses` using a reference to the `CatalogFramework`. -====== Create, Update, and Delete Methods +==== Create, Update, and Delete Methods Create, Update, and Delete (CUD) methods add, change, or remove stored metadata in the local Catalog Provider. @@ -64,7 +64,7 @@ public DeleteResponse delete(DeleteRequest deleteRequest) throws IngestException CUD operations process `PolicyPlugin`, `AccessPlugin`, and `PreIngestPlugin` instances before execution and `PostIngestPlugin` instances after execution. -====== Query Methods +==== Query Methods Query methods search metadata from available Sources based on the `QueryRequest` properties and Federation Strategy. Sources could include Catalog Provider, Connected Sources, and Federated Sources. @@ -77,7 +77,7 @@ public QueryResponse query(QueryRequest queryRequest, FederationStrategy strateg ---- Query requests process  `PolicyPlugin`, `AccessPlugin`, and `PreQueryPlugin` instances before execution and  `PolicyPlugin`, `AccessPlugin`, and `PostQueryPlugin` instances after execution. -====== Resource Methods +==== Resource Methods Resource methods retrieve data resources from Sources. @@ -90,7 +90,7 @@ public ResourceResponse getResource(ResourceRequest request, String resourceSite ---- Resource requests process ``PreResourcePlugin``s before execution and ``PostResourcePlugin``s after execution. -====== Source Methods +==== Source Methods Source methods can get a list of Source identifiers or request descriptions about Sources. @@ -101,7 +101,7 @@ public Set getSourceIds(); public SourceInfoResponse getSourceInfo(SourceInfoRequest sourceInfoRequest) throws SourceUnavailableException; ---- -====== Transform Methods +==== Transform Methods Transform methods provide convenience methods for using Metacard Transformers and Query Response Transformers. @@ -115,7 +115,7 @@ public BinaryContent transform(Metacard metacard, String transformerId, Map requestProperties) throws CatalogTransformerException; ---- -===== Implementing Catalog Methods +=== Implementing Catalog Methods .Query Response Transform Example [source,java,linenums] @@ -142,7 +142,7 @@ private void convert(QueryResponse queryResponse ) { } ---- -===== Dependency Injection +=== Dependency Injection Using Blueprint or another injection framework, transformers can be injected from the OSGi Service Registry. .Blueprint Service Reference @@ -177,7 +177,7 @@ ${ddf-branding}.catalog.transform.QueryResponseTransformer queryResponseTransfor BinaryContent content = queryResponseTransformer.transform(sourceSesponse, arguments); ---- -===== OSGi Service Registry +=== OSGi Service Registry [IMPORTANT] ==== diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-filters.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-filters.adoc index 003f7066dd8d..7822a66caf4c 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-filters.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-filters.adoc @@ -31,7 +31,7 @@ The OGC Filter Specification has several types of filters that can be combined i * Spatial Operators * Temporal Operators -==== Units of Measure +== Units of Measure According to the http://www.opengeospatial.org/standards/filter[OGC Filter Specifications: 09-026r1] {external-link} and http://www.opengeospatial.org/standards/filter[OGC Filter Specifications: 04-095] {external-link}, units of measure can be expressed as a URI. To fulfill that requirement, ${branding} utilizes the GeoTools class `org.geotools.styling.UomOgcMapping` for spatial filters requiring a standard for units of measure for scalar distances. @@ -44,7 +44,7 @@ This class provides three options for units of measure:  ${branding} only supports FOOT and METRE since they are the most applicable to scalar distances. -==== Filter Examples +== Filter Examples The example below illustrates creating a query, and thus an OGC Filter, that does a case-insensitive search for the phrase "mission" in the entire metacard's text. Note that the OGC `PropertyIsLike` Filter is used for this simple contextual query. @@ -86,7 +86,7 @@ org.opengis.filter.Filter filter = filterFactory.during( filterFactory.property( ${ddf-branding}.catalog.operation.QueryImpl query = new QueryImpl(filter) ; ---- -===== Contextual Searches +=== Contextual Searches Most contextual searches can be expressed using the `PropertyIsLike` filter. The special characters that have meaning in a `PropertyIsLike` filter are the wildcard, single wildcard, and escape characters (see Example Creating-Filters-1). @@ -130,7 +130,7 @@ wildcardChar, singleChar, escapeChar, isCaseSensitive) ${ddf-branding}.catalog.operation.QueryImpl query = new QueryImpl( filter ); ---- -====== Tree View of Creating Filters  +==== Tree View of Creating Filters  Filters used in ${branding} can always be represented in a tree diagram. @@ -151,7 +151,7 @@ Filters used in ${branding} can always be represented in a tree diagram. \--------------------/ .... -====== XML View of Creating Filters +==== XML View of Creating Filters Another way to view this type of Filter is through an XML model, which is shown below. @@ -174,7 +174,7 @@ Another way to view this type of Filter is through an XML model, which is shown Using the Logical Operators and `PropertyIsLike` filters, a developer can create a whole language of search phrase expressions. -===== Fuzzy Operations +=== Fuzzy Operations ${branding} only supports one custom function. The Filter specification does not include a fuzzy operator, so a Filter function was created to represent a fuzzy operation. @@ -203,7 +203,7 @@ Filter fuzzyFilter = filterFactory.like( QueryImpl query = new QueryImpl(fuzzyFilter); ---- -==== Parsing Filters +== Parsing Filters According to the http://www.opengeospatial.org/standards/filter[OGC Filter Specification 04-095] {external-link}: a "(filter expression) representation can be ... parsed and then transformed into whatever target language is required to retrieve or modify object instances stored in some persistent object store." Filters can be thought of as the `WHERE` clause for a SQL SELECT statement to "fetch data stored in a SQL-based relational database."  @@ -221,7 +221,7 @@ The simplest approach when using `FilterVisitor` instances is to build the app For instance, when given an incoming `Filter` object to be evaluated against a RDBMS, a `CatalogProvider` instance could use a `FilterVisitor` to interpret each filter operation on the `Filter` object and translate those operations into SQL. The `FilterVisitor` may be needed to support `Filter` functionality not currently handled by the `FilterAdapter` and `FilterDelegate` reference implementation. -===== Interpreting a Filter to Create SQL +=== Interpreting a Filter to Create SQL If the `FilterAdapter` encountered or "visited" a `PropertyIsLike` filter with its property assigned as `title` and its literal expression assigned as `mission`, the `FilterDelegate` could create the proper SQL syntax similar to title `LIKE` mission. @@ -243,7 +243,7 @@ If the `FilterAdapter` encountered or "visited" a `PropertyIsLike` filter wi \-------------------------/ .... -===== Interpreting a Filter to Create XQuery +=== Interpreting a Filter to Create XQuery If the `FilterAdapter` encountered an `OR` filter, such as in Figure Parsing-Filters2 and the target language was XQuery, the `FilterDelegate` could yield an expression such as  @@ -279,7 +279,7 @@ ft:query(//inventory:book/@subject,'science'). .... -====== FilterAdapter/Delegate Process for Figure Parsing +==== FilterAdapter/Delegate Process for Figure Parsing . `FilterAdapter` visits the `OR` filter first. . `OR` filter visits its children in a loop.  @@ -293,7 +293,7 @@ ft:query(//inventory:book/@subject,'science'). . It then collects the output of each child and sends the list of results to the `FilterDelegate OR` method. . The final result object will be returned from the `FilterAdapter` adapt method. -====== FilterVisitor Process for Figure Parsing +==== FilterVisitor Process for Figure Parsing . FilterVisitor visits the `OR` filter first. . `OR` filter visits its children in a loop.  @@ -313,11 +313,11 @@ public visit( Or filter, Object data) { } ---- -==== Filter Profile +== Filter Profile The filter profile maps filters to metacard types. -===== Role of the OGC Filter +=== Role of the OGC Filter Both Queries and Subscriptions extend the OGC GeoAPI Filter interface. @@ -325,7 +325,7 @@ The Filter Builder and Adapter do not fully implement the OGC Filter Specificati The filter support profile contains suggested filter to metacard type mappings. For example, even though a Source could support a `PropertyIsGreaterThan` filter on `XML_TYPE`, it would not likely be useful. -===== Catalog Filter Profile +=== Catalog Filter Profile The following table displays the common metacard attributes with their respective types for reference. @@ -389,7 +389,7 @@ The following table displays the common metacard attributes with their respectiv |=== -====== Comparison Operators +==== Comparison Operators Comparison operators compare the value associated with a property name with a given Literal value. Endpoints and sources should try to use metacard types other than the object type. @@ -612,7 +612,7 @@ Equivalent to SQL "like"  |=== -====== Logical Operators +==== Logical Operators Logical operators apply Boolean logic to one or more child filters. @@ -632,7 +632,7 @@ Logical operators apply Boolean logic to one or more child filters. |=== -====== Temporal Operators +==== Temporal Operators Temporal operators compare a date associated with a property name to a given Literal date or date range. @@ -687,7 +687,7 @@ Literal values can be either date instants or date periods. |=== -====== Spatial Operators +==== Spatial Operators Spatial operators compare a geometry associated with a property name to a given Literal geometry.  diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-plugins.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-plugins.adoc index c20a1b526c3f..dd60921567c4 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-plugins.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-plugins.adoc @@ -89,7 +89,7 @@ The following types of plugins can be created: |=== -==== Implementing Catalog Plugins +== Implementing Catalog Plugins The procedure for implementing any of the plugins follows a similar format: @@ -115,13 +115,13 @@ It is usually preferable to take no action on non-local requests. Refer to the Javadoc for more information on all Requests and Responses in the `${ddf-branding-lowercase}.catalog.operation` and `${ddf-branding-lowercase}.catalog.event` packages. ==== -===== Catalog Plugin Failure Behavior +=== Catalog Plugin Failure Behavior In the event that this Catalog Plugin cannot operate but does not wish to fail the transaction, a `PluginExecutionException` should be thrown. If processing is to be explicitly stopped, a `StopProcessingException` should be thrown. For any other exceptions, the Catalog should "fail fast" and cancel the Operation. -===== Implementing Pre-Ingest Plugins +=== Implementing Pre-Ingest Plugins Develop a custom Pre-Ingest Plugin. @@ -140,7 +140,7 @@ Develop a custom Pre-Ingest Plugin. *Blueprint descriptor example* `` -===== Implementing Post-Ingest Plugins +=== Implementing Post-Ingest Plugins Develop a custom Post-Ingest Plugin. @@ -159,7 +159,7 @@ Develop a custom Post-Ingest Plugin. *Blueprint descriptor example* `` -===== Implementing Pre-Query Plugins +=== Implementing Pre-Query Plugins Develop a custom Pre-Query Plugin @@ -174,7 +174,7 @@ Develop a custom Pre-Query Plugin . Export the service to the OSGi registry. + `` -===== Implementing Post-Query Plugins +=== Implementing Post-Query Plugins Develop a custom Post-Query Plugin @@ -190,7 +190,7 @@ Develop a custom Post-Query Plugin . Export the service to the OSGi registry. + `` -===== Implementing Pre-Delivery Plugins +=== Implementing Pre-Delivery Plugins Develop a custom Pre-Delivery Plugin. @@ -211,7 +211,7 @@ StopProcessingException;` *Blueprint descriptor example* + `` -===== Implementing Pre-Subscription Plugins +=== Implementing Pre-Subscription Plugins Develop a custom Pre-Subscription Plugin. @@ -221,7 +221,7 @@ Develop a custom Pre-Subscription Plugin. . Implement the required method. * `public Subscription process(Subscription input) *throws* PluginExecutionException, StopProcessingException;` -===== Implementing Pre-Resource Plugins +=== Implementing Pre-Resource Plugins Develop a custom Pre-Resource Plugin. @@ -241,7 +241,7 @@ Develop a custom Pre-Resource Plugin. ---- -===== Implementing Post-Resource Plugins +=== Implementing Post-Resource Plugins Develop a custom Post-Resource Plugin. @@ -262,7 +262,7 @@ Develop a custom Post-Resource Plugin. <]]" inter"[[SamplePostResourcePlugin" interface="ddf.catalog.plugin.PostResourcePlugin" /> ---- -===== Implementing Policy Plugins +=== Implementing Policy Plugins Develop a custom Policy Plugin. @@ -283,7 +283,7 @@ Develop a custom Policy Plugin. *Blueprint descriptor example* + `<]]" inter"[[SamplePolicyPlugin" interface="ddf.catalog.plugin.PolicyPlugin" />` -===== Implementing Access Plugins +=== Implementing Access Plugins Develop a custom Access Plugin. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-query-options.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-query-options.adoc index 8da32612244b..28f6c3b2bb19 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-query-options.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-query-options.adoc @@ -32,7 +32,7 @@ filterFactory.literal(value))) ; query.setRequestsTotalResultsCount(true); ---- -==== Evaluating a query +== Evaluating a query Every Source must be able to evaluate a Query object. Nevertheless, each Source could evaluate the Query differently depending on what that Source supports as to properties and query capabilities. @@ -66,15 +66,15 @@ A developer should consult a Source's documentation for the limitations, capabil |=== -==== Commons-DDF Utilities +== Commons-DDF Utilities The `commons-${ddf-branding}` bundle provides utilities and functionality commonly used across other ${branding} components, such as the endpoints and providers.  -===== FuzzyFunction +=== FuzzyFunction `${ddf-branding}.catalog.impl.filter.FuzzyFunction` class is used to indicate that a `PropertyIsLike` filter should interpret the search as a fuzzy query.  -===== XPathHelper +=== XPathHelper `${ddf-branding}.util.XPathHelper` provides convenience methods for executing XPath operations on XML. It also provides convenience methods for converting XML as a `String` from a `org.w3c.dom.Document` object and vice versa. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-readers.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-readers.adoc index c0f37c9c13b8..2f355f1ec87a 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-readers.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-readers.adoc @@ -10,14 +10,14 @@ A simple example is that of a File `ResourceReader`. It takes a file from the local file system and passes it back to ${branding}. New implementations can be created in order to support obtaining Resources from various Resource data stores.  -==== Creating a New `ResourceReader` +== Creating a New `ResourceReader` Complete the following procedure to create a `ResourceReader`. . Create a Java class that implements the `${ddf-branding}.catalog.resource.ResourceReader` interface. . Deploy the OSGi bundled packaged service to the ${branding} run-time. -===== Implementing the `ResourceReader` Interface +=== Implementing the `ResourceReader` Interface [source,java,linenums] ---- @@ -33,7 +33,7 @@ It is recommended to become familiar with the Java API URI class in order to pro Furthermore, a URI should be used according to its http://www.w3.org/Addressing/URL/uri-spec.html[specification] {external-link}. ==== -===== retrieveResource +=== retrieveResource [source,java,linenums] ---- @@ -58,7 +58,7 @@ The `URLResourceReader` is an example `ResourceReader` that reads a file from a The `Map arguments` parameter is passed in to support any options or additional information associated with retrieving the resource. ==== -===== Implement `retrieveResource()` +=== Implement `retrieveResource()` . Define supported schemes (e.g., file, http, etc.). . Check if the incoming URI matches a supported scheme. If it does not, throw `ResourceNotSupportedException`. @@ -103,7 +103,7 @@ return ResourceResponseImpl( new ResourceImpl( new BufferedInputStream( is ), ne If the Resource cannot be found, throw a `ResourceNotFoundException`.   -===== `getSupportedSchemes` +=== `getSupportedSchemes` [source,java] ---- @@ -122,7 +122,7 @@ Additionally, there are other methods that are used to uniquely describe a `Reso The `describe` methods are straight-forward and can be implemented with guidance from the Javadoc. ==== -===== Export to OSGi Service Registry +=== Export to OSGi Service Registry In order for the `ResourceReader` to be used by the `CatalogFramework`, it should be exported to the OSGi Service Registry as a `${ddf-branding}.catalog.resource.ResourceReader`. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-writers.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-writers.adoc index 4f0ebc54226a..5072cd451515 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-writers.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-writers.adoc @@ -8,7 +8,7 @@ A `ResourceWriter` is an object used to store or delete a `Resource`.  `ResourceWriter` objects should be registered within the OSGi Service Registry, so clients can retrieve an instance when they need to store a `Resource`.  -==== Create a New `ResourceWriter` +== Create a New `ResourceWriter` Complete the following procedure to create a `ResourceWriter`. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sources.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sources.adoc index a27fe5c2d52e..6af5189ed791 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sources.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sources.adoc @@ -41,7 +41,7 @@ They let ${branding} perform query and ingest operations on catalog stores and q +----------------------------------------------------------------------------------------------+ .... -==== Implement a Source Interface +== Implement a Source Interface There are three types of sources that can be created to perform query operations. All of these sources must also be able to return their availability and the list of content types currently stored in their back-end data stores. @@ -72,7 +72,7 @@ The `factory-pid` property of the metatype must contain one of the following in Remote sources currently extend the `ResourceReader` interface. However, a `RemoteSource` is not treated as a `ResourceReader`. The `getSupportedSchemes()` method should never be called on a `RemoteSource`, thus the suggested implementation for a `RemoteSource` is to return an empty set. The `retrieveResource( …​ )` and `getOptions( …​ )` methods will be called and MUST be properly implemented by a `RemoteSource`. ==== -===== Developing Catalog Providers +=== Developing Catalog Providers Create a custom implementation of a catalog provider. @@ -95,7 +95,7 @@ Create a custom implementation of a catalog provider. See the <<{managing-prefix}connecting_to_sources,existing Catalog Provider list>> for examples of Catalog Providers included in ${branding}. -===== Developing Federated Sources +=== Developing Federated Sources . Create a Java class that implements `FederatedSource` and `ConfiguredService`. + `public class TestFederatedSource implements ddf.catalog.source.FederatedSource, ddf.catalog.service.ConfiguredService` @@ -110,7 +110,7 @@ See the <<{managing-prefix}connecting_to_sources,existing Catalog Provider list> ---- -===== Developing Connected Sources +=== Developing Connected Sources Create a custom implementation of a connected source. @@ -134,11 +134,11 @@ There may be intermittent failures with the creation of Providers and federated To avoid this issue, create any JAXB within the methods requiring it. ==== -===== Exception Handling +=== Exception Handling In general, sources should only send information back related to the call, not implementation details. -====== Exception Examples +==== Exception Examples Follow these guidelines for effective exception handling: @@ -146,6 +146,6 @@ Follow these guidelines for effective exception handling: * If the caller issues a malformed search request, return an error describing the right form, or specifically what was not recognized in the request. Do not return the exception and stack trace where the parsing broke. * If the caller leaves something out, do not return the null pointer exception with a stack trace, rather return a generic exception with the message "xyz was missing." -====== External Resources for Developing Sources +==== External Resources for Developing Sources * http://today.java.net/pub/a/today/2003/12/04/exceptions.html[Three Rules for Effective Exception Handling] {external-link}. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sts-claims-handlers.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sts-claims-handlers.adoc index 966157ad79f7..86a1ec5f3a7f 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sts-claims-handlers.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-sts-claims-handlers.adoc @@ -310,14 +310,14 @@ This XML file is found inside of the STS bundle and is named `ws-trust-1.4-servi ---- -==== Example Requests and Responses for SAML Assertions +== Example Requests and Responses for SAML Assertions A client performs a RequestSecurityToken operation against the STS to receive a SAML assertion. The ${branding} STS offers several different ways to request a SAML assertion. For help in understanding the various request and response formats, samples have been provided. The samples are divided out into different request token types. -==== BinarySecurityToken (CAS) SAML Security Token Samples +== BinarySecurityToken (CAS) SAML Security Token Samples Most endpoints in ${branding} require the X.509 PublicKey SAML assertion. @@ -537,7 +537,7 @@ A Bearer SAML assertion is automatically trusted by the endpoint. The client doesn't have to prove it can own that SAML assertion. It is the simplest way to request a SAML assertion, but many endpoints won't accept a KeyType of Bearer. -==== UsernameToken Bearer SAML Security Token Sample +== UsernameToken Bearer SAML Security Token Sample * WS-Addressing header with Action, To, and Message ID * Valid, non-expired timestamp @@ -733,7 +733,7 @@ Most of the endpoints that have been used with ${branding} require a SAML v2.0 a This means that the SAML assertion provided by the client to a ${branding} endpoint must contain a SubjectConfirmation block with a type of "holder-of-key" containing the client's public key. This is used to prove that the client can possess the SAML assertion returned by the STS. -==== X.509 PublicKey SAML Security Token Sample +== X.509 PublicKey SAML Security Token Sample .X.509 PublicKey SAML Security Token Request The STS that comes with ${branding} requires the following to be in the RequestSecurityToken request in order to issue a valid SAML assertion. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-input.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-input.adoc index 51880c60a195..6fda28c93447 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-input.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-input.adoc @@ -55,7 +55,7 @@ ${branding} supports the creation of custom <<{architecture-prefix}types_of_tran + . Deploy OSGi Bundle to OSGi runtime. -==== Create an XML Input Transformer using SaxEventHandlers [[saxEventHandlers]] +== Create an XML Input Transformer using SaxEventHandlers [[saxEventHandlers]] For a transformer to transform XML, (as opposed to JSON or a Word document, for example) there is a simpler solution than fully implementing a `MetacardValidator`. DDF includes an extensible, configurable `XmlInputTransformer`. @@ -127,11 +127,11 @@ This is pertinent because a metacards attributes are only stored in the `Catalog Since the `DynamicMetacardType` is constructed dynamically, attributes are declared by the `SaxEventHandlerFactory` that parses them, as opposed to the `MetacardType`. See `org.codice.ddf.transformer.xml.streaming.impl.XmlSaxEventHandlerFactoryImpl.java` vs `ddf.catalog.data.impl.BasicTypes.java` ==== -==== Create an Input Transformer Using Apache Camel +== Create an Input Transformer Using Apache Camel Alternatively, make an Apache Camel route in a blueprint file and deploy it using a feature file or via hot deploy. -===== Input Transformer Design Pattern (Camel) +=== Input Transformer Design Pattern (Camel) Follow this design pattern for compatibility: @@ -192,7 +192,7 @@ This will ensure that the value is taken exactly as is, and is especially useful An example of using an Apache Camel route to define an `InputTransformer` in a blueprint file and deploying it as a bundle to an OSGi container can be found in the ${branding} SDK examples at `${ddf-branding}/sdk/sample-transformers/xslt-identity-input-transformer` ==== -==== Input Transformer Boot Service Flag +== Input Transformer Boot Service Flag The `org.codice.ddf.platform.bootflag.BootServiceFlag` service with a service property of `id=inputTransformerBootFlag` is used to indicate certain Input Transformers are ready in the system. -Adding an Input Transformers ID to a new or existing JSON file under `${home_directory}/etc/transformers` will cause the service to wait for an Input Transformer with the given ID. \ No newline at end of file +Adding an Input Transformers ID to a new or existing JSON file under `${home_directory}/etc/transformers` will cause the service to wait for an Input Transformer with the given ID. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-metacard.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-metacard.adoc index 6a986cc9fc3a..d38b2669c819 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-metacard.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-transformers-metacard.adoc @@ -9,7 +9,7 @@ In general, a `MetacardTransformer` is used to transform a `Metacard` into some Programmatically, a `MetacardTransformer` transforms a `Metacard` into a `BinaryContent` instance, which translates the `Metacard` into the desired final format. Metacard transformers can be used through the Catalog Framework `transform` convenience method or requested from the OSGi Service Registry by endpoints or other bundles. -==== Creating a New Metacard Transformer +== Creating a New Metacard Transformer Existing metacard transformers are written as Java classes, and these steps walk through the steps to create a custom metacard transformer. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-xacml-policies.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-xacml-policies.adoc index f6d62deddec1..e225744b3c9c 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-xacml-policies.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/custom-xacml-policies.adoc @@ -21,23 +21,23 @@ In the examples below, the policy has specified targets for the above type of ca For the Filtering code, the target was set for "filter", and the Service validation code targets were geared toward two services: `query` and `LocalSiteName`. In a production environment, these actions for service authorization will generally be full URNs that are described within the SOAP WSDL. -==== XACML Policy Attributes +== XACML Policy Attributes Attributes for the XACML request are populated with the information in the calling subject and the resource being checked. -==== XACML Policy Subject +== XACML Policy Subject The attributes for the subject are obtained from the SAML claims and populated within the XACML policy as individual attributes under the `urn:oasis:names:tc:xacml:1.0:subject-category:access-subject` category. The name of the claim is used for the `AttributeId` value. Examples of the items being populated are available at the end of this page. -==== XACML Policy Resource +== XACML Policy Resource The attributes for resources are obtained through the permissions process. When checking permissions, the XACML processing engine retrieves a list of permissions that should be checked against the subject. These permissions are populated outside of the engine and should be populated with the attributes that should be asserted against the subject. When the permissions are of a key-value type, the key being used is populated as the AttributeId value under the urn:oasis:names:tc:xacml:3.0:attribute-category:resource category. -==== Using a XACML Policy +== Using a XACML Policy To use a XACML policy, copy the XACML policy into the `${home_directory}/etc/pdp/policies` directory. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/default-attribute-values.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/default-attribute-values.adoc index a58efe6bfb99..5a2979ef7ad7 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/default-attribute-values.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/default-attribute-values.adoc @@ -7,7 +7,7 @@ Create custom default attribute types. -==== Default Attribute Values +== Default Attribute Values To define default attribute values, the definition file must have a `defaults` key in the root object. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/editing-docs.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/editing-docs.adoc index bdbab07863f8..69d816bd6860 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/editing-docs.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/editing-docs.adoc @@ -28,7 +28,7 @@ ${branding} documentation is included in the source code, so it is edited and ma |Properties file defining content types and other parameters. |=== -==== Editing Existing Documentation +== Editing Existing Documentation Update existing content when code behavior changes, new capabilities are added to features, or the configuration process changes. Content is organized within the `content` directory in sub directories according to the audience and purpose for each document in the documentation library. @@ -57,7 +57,7 @@ Documentation:: This is a collection of all of the individual documentation page See the https://codice.atlassian.net/wiki/spaces/DDF/pages/6291516/Documentation+Style+Guide[style guide] for more guidance on stylistic and formatting concerns. -==== Adding New Documentation Content +== Adding New Documentation Content If creating a new section is required, there are some minimal requirements for a new `.adoc` file. @@ -71,14 +71,14 @@ Different sections have different headers required, but some common attributes a * `order`: used in sections where order needs to be enforced. * `summary`: brief summary of section contents. Some, but not all, summaries are included by templates. -==== Creating a New Documentation Template +== Creating a New Documentation Template To create a new, standalone documentation page, create a new template in the `templates` directory. Optionally, this template can `include` some of the internal templates in the `templates/build` directory, but this is not required. For guidance on using the freemarker syntax, see the https://freemarker.apache.org/docs/ref.html[Freemarker documentation] {external-link}. -==== Extending Documentation in Downstream Distributions +== Extending Documentation in Downstream Distributions By mimicking the build and directory structure of the documentation, downstream projects are able to leverage the existing documentation and insert content before and after sections of the ${branding} documentation. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/filter-delegates.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/filter-delegates.adoc index 716ec50fceea..56484b8a30f9 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/filter-delegates.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/filter-delegates.adoc @@ -8,12 +8,12 @@ Filter Delegates help reduce the complexity of parsing OGC Filters. The reference Filter Adapter implementation contains the necessary boilerplate visitor code and input normalization to handle commonly supported OGC Filters. -==== Creating a New Filter Delegate +== Creating a New Filter Delegate A Filter Delegate contains the logic that converts normalized filter input into a form that the target data source can handle. Delegate methods will be called in a depth first order as the Filter Adapter visits filter nodes. -===== Implementing the Filter Delegate +=== Implementing the Filter Delegate . Create a Java class extending `FilterDelegate`. + `public class ExampleDelegate extends ${ddf-branding}.catalog.filter.FilterDelegate {` @@ -24,12 +24,12 @@ Delegate methods will be called in a depth first order as the Filter Adapter vis A code example of a Filter Delegate can be found in `${ddf-branding}.catalog.filter.proxy.adapter.test` of the `filter-proxy` bundle. ==== -===== Throwing Exceptions +=== Throwing Exceptions Filter delegate methods can throw `UnsupportedOperationException` run-time exceptions. The `GeotoolsFilterAdapterImpl` will catch and re-throw these exceptions as `UnsupportedQueryExceptions`. -===== Using the Filter Adapter +=== Using the Filter Adapter The FilterAdapter can be requested from the OSGi registry. @@ -59,7 +59,7 @@ public ${ddf-branding}.catalog.operation.QueryResponse query(${ddf-branding}.cat Import the ${ddf-catalog} API Filter package and the reference implementation package of the Filter Adapter in the bundle manifest (in addition to any other required packages). + `Import-Package: ${ddf-branding}.catalog, ${ddf-branding}.catalog.filter, ${ddf-branding}.catalog.source` -===== Filter Support +=== Filter Support Not all OGC Filters are exposed at this time. If demand for further OGC Filter functionality is requested, it can be added to the Filter Adapter and Delegate so sources can support more complex filters. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/global-attribute-validators.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/global-attribute-validators.adoc index 65f3685fbb3a..eb103b8ded91 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/global-attribute-validators.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/global-attribute-validators.adoc @@ -5,7 +5,7 @@ :summary: Creating a custom global attribute validator. :order: 02 -==== Global Attribute Validators File +== Global Attribute Validators File To define Validators, the definition file must have a `validators` key in the root object. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/json-definition-files.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/json-definition-files.adoc index 5ff1de902847..e60c2b592df2 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/json-definition-files.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/json-definition-files.adoc @@ -15,7 +15,7 @@ The following may be defined in a JSON definition file: - <<{developing-prefix}default_attribute_values,Default Attribute Values>> - <<{developing-prefix}attribute_injection_definition,Attribute Injections>> -==== Definition File Format +== Definition File Format A definition file follows the JSON format as specified in http://www.ecma-international.org/publications/standards/Ecma-404.htm[ECMA-404] {external-link}. All definition files must be valid JSON in order to be parsed. @@ -23,7 +23,7 @@ All definition files must be valid JSON in order to be parsed. A single definition file may define as many of the types as needed. This means that types can be defined across multiple files for grouping or clarity. -==== Deploying Definition Files +== Deploying Definition Files The file must have a `.json` extension in order to be picked up by the deployer. Once the definition file is ready to be deployed, put the definition file `.json` into the `etc/definitions` folder. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/managed-service-factories.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/managed-service-factories.adoc index e0c6ef138763..629470564ae3 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/managed-service-factories.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/managed-service-factories.adoc @@ -16,7 +16,7 @@ Also, a new service will be created and configured every time a configuration fi Any `service.factoryPid` and `service.pid` values in these `.config` files will be overridden by the values parsed from the file name, so `.config` files should not contain these properties. -==== File Format +== File Format The basic syntax of the `.config` configuration files is similar to the older `.cfg` files but introduces support for lists and types other than simple strings. The type associated with a property must match the type attribute used in the corresponding `metatype.xml` file when applicable. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-type.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-type.adoc index 9afa23c3c32b..98d5ba6ea99f 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-type.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-type.adoc @@ -7,7 +7,7 @@ Create custom Metacard types with Metacard Type definition files. -==== Metacard Type Definition File +== Metacard Type Definition File To define Metacard Types, the definition file must have a `metacardTypes` key in the root object. diff --git a/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-validators.adoc b/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-validators.adoc index 32ee44f33164..b31e33e712e2 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-validators.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devComponents/metacard-validators.adoc @@ -5,7 +5,7 @@ :summary: Creating a custom metacard validator. :order: 02 -==== Metacard Validator Definition +== Metacard Validator Definition Metacard Validator definitions are similar to the Validators definitions. To define Metacard Validators, your definition file must have a `metacardvalidators` key in the root object. diff --git a/distribution/docs/src/main/resources/content/_developing/_devGuidelines/osgi-basics.adoc b/distribution/docs/src/main/resources/content/_developing/_devGuidelines/osgi-basics.adoc index f4c368fbced3..c5b0485ec402 100644 --- a/distribution/docs/src/main/resources/content/_developing/_devGuidelines/osgi-basics.adoc +++ b/distribution/docs/src/main/resources/content/_developing/_devGuidelines/osgi-basics.adoc @@ -24,7 +24,7 @@ Bundle:: Java Archives (JARs) with special OSGi manifest entries. Feature:: One or more bundles that form an installable unit; defined by Apache Karaf but portable to other OSGi containers. Application:: A JSON file defining a collection of bundles with configurations to be displayed in the ${admin-console}. -==== Packaging Capabilities as Bundles +== Packaging Capabilities as Bundles Services and code are physically deployed to ${branding} using bundles. The bundles within ${branding} are created using the maven bundle plug-in. @@ -40,9 +40,9 @@ Using Maven is not necessary to create bundles. Many alternative tools exist, and OSGi manifest files can also be created by hand, although hand-editing should be avoided by most developers. ==== -===== Creating a Bundle +=== Creating a Bundle -====== Bundle Development Recommendations +==== Bundle Development Recommendations Avoid creating bundles by hand or editing a manifest file:: Many tools exist for creating bundles, notably the Maven Bundle plugin, which handle the details of OSGi configuration and automate the bundling process including generation of the manifest file. Always make a distinction on which imported packages are `optional` or `required`:: Requiring every package when not necessary can cause an unnecessary dependency ripple effect among bundles. @@ -56,7 +56,7 @@ Bundles separate contract from implementation and allow for modularized developm For that to be effective, they must be defined and used correctly so inadvertent coupling does not occur. Good bundle definition and usage leads to a more flexible environment. -====== Maven Bundle Plugin +==== Maven Bundle Plugin Below is a code snippet from a Maven `pom.xml` for creating an OSGi Bundle using the Maven Bundle plugin. @@ -88,7 +88,7 @@ Below is a code snippet from a Maven `pom.xml` for creating an OSGi Bundle using ... ---- -===== Third Party and Utility Bundles +=== Third Party and Utility Bundles It is recommended to avoid building directly on included third party and utility bundles. These components do provide utility and reuse potential; however, they may be upgraded or even replaced at anytime as bug fixes and new capabilities dictate. @@ -99,7 +99,7 @@ If building on these components, be aware of the version upgrades with each dist Instead, component developers should package and deliver their own dependencies to ensure future compatibility. For example, if re-using a bundle, the specific bundle version that you are depending on should be included in your packaged release, and the proper versions should be referenced in your bundle(s). -===== Deploying a Bundle +=== Deploying a Bundle A bundle is typically installed in one of two ways: @@ -115,7 +115,7 @@ In addition, Karaf also supports exploded bundles and custom deployers (Blueprin Once deployed, the bundle should come up in the Active state, if all of the dependencies were properly met. When this occurs, the service is available to be used. -===== Verifying Bundle State +=== Verifying Bundle State To verify if a bundle is deployed and running, go to the running command console and view the status. diff --git a/distribution/docs/src/main/resources/content/_integrating/_endpoints/csw-endpoint.adoc b/distribution/docs/src/main/resources/content/_integrating/_endpoints/csw-endpoint.adoc index 4cd798269a25..25a00b300ae6 100644 --- a/distribution/docs/src/main/resources/content/_integrating/_endpoints/csw-endpoint.adoc +++ b/distribution/docs/src/main/resources/content/_integrating/_endpoints/csw-endpoint.adoc @@ -163,7 +163,7 @@ A successful ingest will return a status of `200 OK` and `csw:TransactionRespons === CSW Endpoint Query Examples -To query through the CSW Enpoint, send a `POST` request to the CSW endpoint. +To query through the CSW Endpoint, send a `POST` request to the CSW endpoint. .CSW Endpoint Query URL [source,http] diff --git a/distribution/docs/src/main/resources/content/_integrating/_eventing/subscriptions.adoc b/distribution/docs/src/main/resources/content/_integrating/_eventing/subscriptions.adoc index e9f194462dc4..68512374603e 100644 --- a/distribution/docs/src/main/resources/content/_integrating/_eventing/subscriptions.adoc +++ b/distribution/docs/src/main/resources/content/_integrating/_eventing/subscriptions.adoc @@ -8,26 +8,26 @@ Subscriptions represent "standing queries" in the Catalog. Like a query, subscriptions are based on the OGC Filter specification. -==== Subscription Lifecycle +== Subscription Lifecycle A Subscription itself is a series of events during which various plugins or transformers can be called to process the subscription. -===== Creation +=== Creation * Subscriptions are created directly with the <<{architecture-prefix}event_processor,Event Processor>> or declaratively through use of the Whiteboard Design Pattern. * The Event Processor will invoke each Pre-Subscription Plugin and, if the subscription is not rejected, the subscription will be activated. -===== Evaluation +=== Evaluation * When a metacard matching the subscription is created, updated, or deleted in any Source, each Pre-Delivery Plugin will be invoked. * If the delivery is not rejected, the associated Delivery Method callback will be invoked. -===== Update Evaluation +=== Update Evaluation Notably, the Catalog allows event evaluation on both the previous value (if available) and new value of a Metacard when an update occurs. -===== Durability +=== Durability Subscription durability is not provided by the Event Processor. Thus, all subscriptions are transient and will not be recreated in the event of a system restart. @@ -42,7 +42,7 @@ The Catalog Framework, or more specifically the Event Processor itself, does not Certain endpoints, however, can persist the subscriptions on their own and recreate them on system startup. ==== -==== Creating a Subscription +== Creating a Subscription Currently, the Catalog reference implementation does not contain a subscription endpoint. Therefore, an endpoint that exposes a web service interface to create, update, and delete subscriptions would provide a client's subscription filtering criteria to be used by Catalog's Event Processor to determine which events are of interest to the client. @@ -55,7 +55,7 @@ Therefore, the client must ensure the event consumer is running prior to creatin The Catalog completes the subscription creation by executing any pre-subscription Catalog Plugins, and then registering the subscription with the OSGi Service Registry. The Catalog does not persist subscriptions by default. -===== Event Processing and Notification +=== Event Processing and Notification If an event matches a subscription's criteria, any pre-delivery plugins that are installed are invoked, the subscription's `DeliveryMethod` is retrieved, and its operation corresponding to the type of ingest event is invoked.  For example, the `DeliveryMethod` `created()` function is called when a metacard is created. @@ -75,7 +75,7 @@ When an event matches a subscription's criteria the Standard Event Processor: .Available Event Processor * <<{architecture-prefix}event_processor,Standard Event Processor>> -====== Using ${branding} Implementation +==== Using ${branding} Implementation If applicable, the implementation of `Subscription` that comes with ${branding} should be used. It is available at `ddf.catalog.event.impl.SubscriptionImpl` and offers a constructor that takes in all of the necessary objects. @@ -103,7 +103,7 @@ boolean isEnterprise = true; Subscription subscription = new SubscriptionImpl(filter, deliveryMethod, sourceIds,isEnterprise); ---- -===== Delivery Method +=== Delivery Method A Delivery Method provides the operation (created, updated, deleted) for how an event's metacard can be delivered. diff --git a/distribution/docs/src/main/resources/content/_managing/_configuring/configuring-oidc.adoc b/distribution/docs/src/main/resources/content/_managing/_configuring/configuring-oidc.adoc index a3b0d4b7dda1..f948fa3d78db 100644 --- a/distribution/docs/src/main/resources/content/_managing/_configuring/configuring-oidc.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_configuring/configuring-oidc.adoc @@ -5,12 +5,12 @@ :summary: Configuring included IdP. :order: 03 -==== {title} +== {title} To use https://openid.net/specs/openid-connect-core-1_0.html[OpenID Connect (OIDC)] and https://tools.ietf.org/html/rfc6749[OAuth 2.0], ${branding} needs to be connected to an external Identity Provider (IdP) which supports these protocols. -===== OIDC +=== OIDC OIDC is used to authenticate (or log in) a user. To use this protocol in ${branding}, ${branding} needs the external IdP's information. @@ -28,7 +28,7 @@ Once connected, the Web Context Policy Manager needs to be updated. to do so, . Select the *Web Context Policy Manager*. . Under `Authentication Types for Web Pages` and `Authentication Types for Endpoints` add OIDC. -===== OAuth 2.0 +=== OAuth 2.0 OAuth 2.0 is an authorization protocol and ${branding} can use it when federating. When a user queries a source that is configured to use this protocol, ${branding} will forward the user's information (access token) with the request. diff --git a/distribution/docs/src/main/resources/content/_managing/_installing/hardware-reqs.adoc b/distribution/docs/src/main/resources/content/_managing/_installing/hardware-reqs.adoc index 89fd2bd0bfa8..5e24b81de10e 100644 --- a/distribution/docs/src/main/resources/content/_managing/_installing/hardware-reqs.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_installing/hardware-reqs.adoc @@ -67,5 +67,6 @@ Debian 9 Microsoft Edge + Firefox + Chrome +|=== ===== diff --git a/distribution/docs/src/main/resources/content/_installing/java-reqs.adoc b/distribution/docs/src/main/resources/content/_managing/_installing/java-reqs.adoc similarity index 100% rename from distribution/docs/src/main/resources/content/_installing/java-reqs.adoc rename to distribution/docs/src/main/resources/content/_managing/_installing/java-reqs.adoc diff --git a/distribution/docs/src/main/resources/content/_managing/_running/ddf-service.adoc b/distribution/docs/src/main/resources/content/_managing/_running/ddf-service.adoc index 6e39e519caa2..8fadd6d24653 100644 --- a/distribution/docs/src/main/resources/content/_managing/_running/ddf-service.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_running/ddf-service.adoc @@ -5,9 +5,9 @@ :project: ${branding} :order: 07 -==== {title} +== {title} -===== Running as a Service with Automatic Start on System Boot +=== Running as a Service with Automatic Start on System Boot Because ${branding} is built on top of Apache Karaf, ${branding} can use the Karaf Wrapper to run ${branding} as a service and enable automatic startup and shutdown. When ${branding} is started using Karaf Wrapper, new `wrapper.log` and `wrapper.log.n` (where n goes from 1 to 5 by default) log files will be generated to include wrapper and console specific information. @@ -95,7 +95,7 @@ ${home_directory}\bin\${branding-lowercase}-service.bat install Startup and shutdown settings can then be managed through *Services -> MMC Start -> Control Panel -> Administrative Tools -> Services*. -===== Karaf Documentation +=== Karaf Documentation Because ${branding} is built on top of Apache Karaf, more information on operating ${branding} can be found in the http://karaf.apache.org/index/documentation.html[Karaf documentation] {external-link}. diff --git a/distribution/docs/src/main/resources/content/_managing/_running/monitoring.adoc b/distribution/docs/src/main/resources/content/_managing/_running/monitoring.adoc index 16278427b8ac..7ed5df84830a 100644 --- a/distribution/docs/src/main/resources/content/_managing/_running/monitoring.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_running/monitoring.adoc @@ -6,46 +6,46 @@ The ${branding} contains many tools to monitor system functionality, usage, and overall system health. -==== Metrics Reporting +== Metrics Reporting Metrics are exposed over a Prometheus endpoint at `/metrics`. In order to extract and store the metrics, a Prometheus server is required. A user interface like Grafana can be used to display metrics. -==== Managing Logging +== Managing Logging The ${branding} supports a dynamic and customizable logging system including log level, log format, log output destinations, roll over, etc. -===== Configuring Logging +=== Configuring Logging Edit the configuration file `${home_directory}/etc/org.ops4j.pax.logging.cfg]` -===== ${branding} log file +=== ${branding} log file The name and location of the log file can be changed with the following setting: `log4j.appender.out.file=${home_directory}/data/log/${branding-lowercase}.log` -===== Controlling log level +=== Controlling log level A useful way to debug and detect issues is to change the log level: `log4j.rootLogger=DEBUG, out, osgi:VmLogAppender` -===== Controlling the size of the log file +=== Controlling the size of the log file Set the maximum size of the log file before it is rolled over by editing the value of this setting: `log4j.appender.out.maxFileSize=20MB` -===== Number of backup log files to keep +=== Number of backup log files to keep Adjust the number of backup files to keep by editing the value of this setting: `log4j.appender.out.maxBackupIndex=10` -===== Enabling logging of inbound and outbound SOAP messages for the ${branding} SOAP endpoints +=== Enabling logging of inbound and outbound SOAP messages for the ${branding} SOAP endpoints By default, the ${branding} start scripts include a system property enabling logging of inbound and outbound SOAP messages. @@ -55,13 +55,13 @@ In order to see the messages in the log, one must set the logging level for `org `${branding-lowercase}${at-symbol}local>log:set INFO org.apache.cxf.services` -===== Logging External Resources +=== Logging External Resources Other appenders can be selected and configured. For more detail on configuring the log file and what is logged to the console see: http://karaf.apache.org/manual/latest/#_log[Karaf Documentation: Log] {external-link}. -===== Enabling HTTP Access Logging +=== Enabling HTTP Access Logging To enable access logs for the current ${branding}, do the following: @@ -101,7 +101,7 @@ This is the most popular format for access logs and can be parsed by many web se 127.0.0.1 - - [14/Jan/2013:16:21:33 +0000] "GET /favicon.ico HTTP/1.1" 200 0 ---- -===== Using the LogViewer +=== Using the LogViewer * Navigate to the ${admin-console} * Navigate to the *System* tab diff --git a/distribution/docs/src/main/resources/content/_managing/_running/os-services.adoc b/distribution/docs/src/main/resources/content/_managing/_running/os-services.adoc index 0be5c26418cb..cb4fb87d9905 100644 --- a/distribution/docs/src/main/resources/content/_managing/_running/os-services.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_running/os-services.adoc @@ -5,7 +5,7 @@ :project: ${branding} :order: 03 -=== {title} +== {title} The lifecycle of ${branding} and Solr processes can be managed by the operating system. The ${branding} documentation provides instructions to install diff --git a/distribution/docs/src/main/resources/content/_managing/_running/solr-service.adoc b/distribution/docs/src/main/resources/content/_managing/_running/solr-service.adoc index 1ea32fd69e82..7731610a597c 100644 --- a/distribution/docs/src/main/resources/content/_managing/_running/solr-service.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_running/solr-service.adoc @@ -5,6 +5,6 @@ :project: ${branding} :order: 05 -==== {title} +== {title} Refer to https://lucene.apache.org/solr/guide/${solr.docs.version}/taking-solr-to-production.html[Taking Solr to Production] {external-link} in the Solr documentation for configuring Solr as a Windows or init.d service. diff --git a/distribution/docs/src/main/resources/content/_managing/_running/starting-intro.adoc b/distribution/docs/src/main/resources/content/_managing/_running/starting-intro.adoc index 2cdfbe1a1769..ce6e77ed105f 100644 --- a/distribution/docs/src/main/resources/content/_managing/_running/starting-intro.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_running/starting-intro.adoc @@ -6,7 +6,7 @@ Follow the below steps to start and stop ${branding}. -==== Starting from Startup Scripts +== Starting from Startup Scripts Run one of the start scripts from a command shell to start the distribution and open a local console: @@ -20,7 +20,7 @@ ${home_directory}/bin/${branding-lowercase} ${home_directory}/bin/${branding-lowercase}.bat ---- -==== Starting as a Background Process +== Starting as a Background Process Alternatively, to run ${branding} as a background process, run the `start` script: @@ -51,7 +51,7 @@ ${home_directory}/bin/client.bat -h Use the `-h` option followed by the name (``) or IP of the host where ${branding} is running. ==== -==== Stopping ${branding} +== Stopping ${branding} There are two options to stop a running instance: diff --git a/distribution/docs/src/main/resources/content/_managing/_running/troubleshooting-ui.adoc b/distribution/docs/src/main/resources/content/_managing/_running/troubleshooting-ui.adoc index 51a1bf28afc2..2f90c6448685 100644 --- a/distribution/docs/src/main/resources/content/_managing/_running/troubleshooting-ui.adoc +++ b/distribution/docs/src/main/resources/content/_managing/_running/troubleshooting-ui.adoc @@ -4,7 +4,7 @@ :summary: Troubleshooting UI issues. :order: 01 -==== Deleted Records Are Being Displayed In The Search UI's Search Results +== Deleted Records Are Being Displayed In The Search UI's Search Results When queries are issued by the Search UI, the query results that are returned are also cached in an internal Solr database for faster retrieval when the same query may be issued in the future. As records are deleted from the catalog provider, this Solr cache is kept in sync by also deleting the same records from the cache if they exist. diff --git a/distribution/docs/src/main/resources/content/_metadataReference/validation-attributes-table.adoc b/distribution/docs/src/main/resources/content/_metadataReference/validation-attributes-table.adoc index ab6df72b3b8e..d257dd819232 100644 --- a/distribution/docs/src/main/resources/content/_metadataReference/validation-attributes-table.adoc +++ b/distribution/docs/src/main/resources/content/_metadataReference/validation-attributes-table.adoc @@ -1,4 +1,4 @@ -:title: Validation Attributes +:title: Validation Attributes :type: subMetadataReference :order: 10 :parent: Catalog Taxonomy Definitions diff --git a/distribution/docs/src/main/resources/content/_reference/dependency-list-intro.adoc b/distribution/docs/src/main/resources/content/_reference/dependency-list-intro.adoc index 48b0d89c4092..ea11c3039545 100644 --- a/distribution/docs/src/main/resources/content/_reference/dependency-list-intro.adoc +++ b/distribution/docs/src/main/resources/content/_reference/dependency-list-intro.adoc @@ -4,7 +4,6 @@ :order: 02 :summary: Introduction to dependency list reference. -[{reference}] == {title} This list of ${branding} dependencies is automatically generated: diff --git a/distribution/docs/src/main/resources/content/_using/notifications.adoc b/distribution/docs/src/main/resources/content/_using/notifications.adoc deleted file mode 100644 index e69de29bb2d1..000000000000 diff --git a/distribution/docs/src/main/resources/templates/application-reference.ftl b/distribution/docs/src/main/resources/templates/application-reference.ftl index ec589595db38..8a33a0ddc13a 100644 --- a/distribution/docs/src/main/resources/templates/application-reference.ftl +++ b/distribution/docs/src/main/resources/templates/application-reference.ftl @@ -1,4 +1,4 @@ -[{reference}] + == Application Reference ==== diff --git a/distribution/docs/src/main/resources/templates/architectures-build.ftl b/distribution/docs/src/main/resources/templates/architectures-build.ftl index 56073cda12f6..57621ad2507a 100644 --- a/distribution/docs/src/main/resources/templates/architectures-build.ftl +++ b/distribution/docs/src/main/resources/templates/architectures-build.ftl @@ -4,7 +4,7 @@ == ${ai.title} -include::${ai.file}[] +include::${ai.file}[leveloffset=+1] ''' <#list architectures?sort_by("order") as architecture> @@ -12,13 +12,13 @@ include::${ai.file}[] === ${architecture.title} -include::${architecture.file}[] +include::${architecture.file}[leveloffset=+2] <#list subArchitectures?sort_by("order") as subArchitecture> <#if (subArchitecture.status == "published") && (architecture.title?contains (subArchitecture.parent))> ==== ${subArchitecture.title} -include::${subArchitecture.file}[] +include::${subArchitecture.file}[leveloffset=+3] diff --git a/distribution/docs/src/main/resources/templates/catalog-frameworks.ftl b/distribution/docs/src/main/resources/templates/catalog-frameworks.ftl index 3c94ad7303c8..a85caf6a861e 100644 --- a/distribution/docs/src/main/resources/templates/catalog-frameworks.ftl +++ b/distribution/docs/src/main/resources/templates/catalog-frameworks.ftl @@ -28,7 +28,7 @@ None. ==== ${catalogFramework.title} -include::${catalogFramework.file}[] +include::${catalogFramework.file}[leveloffset=+3] \ No newline at end of file diff --git a/distribution/docs/src/main/resources/templates/developing-components.ftl b/distribution/docs/src/main/resources/templates/developing-components.ftl index 5324812017b4..25ef9e634ebb 100644 --- a/distribution/docs/src/main/resources/templates/developing-components.ftl +++ b/distribution/docs/src/main/resources/templates/developing-components.ftl @@ -8,7 +8,7 @@ Create custom implementations of ${branding} components. === ${developingComponent.title} -include::${developingComponent.file}[] +include::${developingComponent.file}[leveloffset=+2] \ No newline at end of file diff --git a/distribution/docs/src/main/resources/templates/development-guidelines.ftl b/distribution/docs/src/main/resources/templates/development-guidelines.ftl index c2bb89a5313d..6717ebefcf0f 100644 --- a/distribution/docs/src/main/resources/templates/development-guidelines.ftl +++ b/distribution/docs/src/main/resources/templates/development-guidelines.ftl @@ -6,7 +6,7 @@ === ${developmentGuideline.title} -include::${developmentGuideline.file}[] +include::${developmentGuideline.file}[leveloffset=+2] \ No newline at end of file diff --git a/distribution/docs/src/main/resources/templates/managing-build.ftl b/distribution/docs/src/main/resources/templates/managing-build.ftl index 02cdcabfc887..862d8d4aa270 100644 --- a/distribution/docs/src/main/resources/templates/managing-build.ftl +++ b/distribution/docs/src/main/resources/templates/managing-build.ftl @@ -71,7 +71,7 @@ include::${ri.file}[] <#list startingIntros as si> <#if (si.status == "published")> -include::${si.file}[] +include::${si.file}[leveloffset=+2] @@ -104,7 +104,7 @@ include::${subMaintaining.file}[leveloffset=+4] <#list monitorings?sort_by("order") as monitoring> <#if (monitoring.status == "published")> -include::${monitoring.file}[] +include::${monitoring.file}[leveloffset=+2] @@ -113,7 +113,7 @@ include::${monitoring.file}[] <#list troubleshootings?sort_by("order") as troubleshooting> <#if (troubleshooting.status == "published")> -include::${troubleshooting.file}[] +include::${troubleshooting.file}[leveloffset=+2] diff --git a/distribution/docs/src/main/resources/templates/metadata-reference.ftl b/distribution/docs/src/main/resources/templates/metadata-reference.ftl index 2a743629f1b2..c842a969e707 100644 --- a/distribution/docs/src/main/resources/templates/metadata-reference.ftl +++ b/distribution/docs/src/main/resources/templates/metadata-reference.ftl @@ -1,4 +1,3 @@ -[{reference}] <#list metadataIntros?sort_by("order") as mi> <#if mi.status == "published"> include::${mi.file}[] diff --git a/distribution/docs/src/main/resources/templates/plugins.ftl b/distribution/docs/src/main/resources/templates/plugins.ftl index 4762471f2ccd..806eae9746e4 100644 --- a/distribution/docs/src/main/resources/templates/plugins.ftl +++ b/distribution/docs/src/main/resources/templates/plugins.ftl @@ -3,7 +3,7 @@ <#list pluginIntros?sort_by("order") as pi> <#if (pi.order == "00")> -include::${pi.file}[] +include::${pi.file}[leveloffset=+1] <#if (pi.plugintypes != "general")> <<${pi.link},${pi.title}>>:: ${pi.summary} @@ -100,9 +100,9 @@ include::${pi.file}[] <#list pluginIntros?sort_by ("order") as pi> <#if pi.status == "published" && pi.order != ("00") && pi.order != ("9999")> -==== ${pi.title} +==== ${pi.title} -include::${pi.file}[] +include::${pi.file}[leveloffset=+3] ===== Available ${pi.title} @@ -128,7 +128,7 @@ Installation and configuration details listed by plugin name. ==== ${plugin.title} -include::${plugin.file}[] +include::${plugin.file}[leveloffset=+3] ''' diff --git a/distribution/docs/src/main/resources/templates/reference-build.ftl b/distribution/docs/src/main/resources/templates/reference-build.ftl index bf498980d86c..f69fb7dee37f 100644 --- a/distribution/docs/src/main/resources/templates/reference-build.ftl +++ b/distribution/docs/src/main/resources/templates/reference-build.ftl @@ -1,6 +1,5 @@ <#list referenceIntros?sort_by("order") as ri> <#if ri.status == "published"> -[{reference}] include::${ri.file}[] <#list references?sort_by("order") as reference> diff --git a/distribution/docs/src/main/resources/templates/transformers.ftl b/distribution/docs/src/main/resources/templates/transformers.ftl index 36ef99514bbc..8631bac73048 100644 --- a/distribution/docs/src/main/resources/templates/transformers.ftl +++ b/distribution/docs/src/main/resources/templates/transformers.ftl @@ -63,7 +63,7 @@ Availability and configuration details of available transformers. ==== ${transformer.title} -include::${transformer.file}[] +include::${transformer.file}[leveloffset=+3] @@ -93,7 +93,7 @@ None. ==== ${mimeTypeMapper.title} -include::${mimeTypeMapper.file}[] +include::${mimeTypeMapper.file}[leveloffset=+3] @@ -124,7 +124,7 @@ None. ==== ${mimeTypeResolver.title} -include::${mimeTypeResolver.file}[] +include::${mimeTypeResolver.file}[leveloffset=+3] \ No newline at end of file