ISIS-1243: more updates to RO viewer docs

[[_ugvro_simplified-representations]]
= Simplified Representations
:Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR  CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
:_basedir: ../
:_imagesdir: images/

The representations defined by the RO spec are very rich and enable complex client-side applications to be built.
However, their sophistication can be an impediment to their use if one wishes to write a simple app using third-party
components that expect to consume much simpler representations.  Examples of such tools are
link:http://angular-ui.github.io/bootstrap/[Angular Bootstrap],
link:http://vitalets.github.io/angular-xeditable/[Angular XEditable],
link:https://github.com/mgcrea/angular-strap[Angular Strap].

As of `1.11.0-SNAPSHOT`, Apache Isis provides support for its own simplified representation for the most commonly-used
representations.  This is implemented using the `ContentNegotiationService` described in the
xref:ugvro.adoc#_ugvro_architecture[architecture] chapter.

[[_ugvro_simplified-representations_apache-isis-profile]]
== The Apache Isis "Profile"

The RO spec uses the standard `Accept` header for content negotiation, and defines its own "profile" for the standard
representations; these take the form:

[source]
----
Accept: application/json;profile="urn:org.restfulobjects:repr-types/xxx"
----

where "xxx" varies by resource.  The detail can be found in section 2.4.1 of the RO spec.

The Apache Isis viewer also defines its own "Isis" profile which enables the client to request simplified
representations for the most frequently accessed resources.  This is done by specifying an `Accept` header of:

[source]
----
Accept: application/json;profile="urn:org.apache.isis/v1"
----

Not every resource supports this header, but the most commonly accessed ones do.  In each case the server will set the
`Content-Type` header so that the client knows how to process the representation.

The screencast below demonstrates the feature.

video::HMSqapQDY_4[youtube,width="853px",height="480px"]

The sections below explain in a little more detail what is returned when this profile is activated.

[[_ugvro_simplified-representations_domain-object]]
== Domain Object

If a domain object resource (section 14) is accessed with the Apache Isis profile, the resultant representation is a
JSON object with simple key/value pairs for each property.

The contents of any collections are also eagerly returned, consisting of an array of elements of each referenced
object.  Each such element contains key/value pairs of each property (in other words, a grid of data is returned).
Each element also has a special `$$href` property (so that the client can easily navigate to a resource for that
object) and a `$$title` property (to use as a label, eg the hyperlink text).

In addition, the representation defined by the RO spec is also included, under a special `$$ro` property.

For example, using the (non-ASF) http://github.com/isisaddons/isis-app-todoapp[Isis addons' todoapp], accessing
this resource:

[source]
----
http://localhost:8080/restful/objects/TODO/45
----

with an `Accept` request header of:

[source]
----
Accept: application/json;profile="urn:org.apache.isis/v1"
----

returns the following representation:

[source]
----
{
  "$$href" : "http://localhost:8080/restful/objects/TODO/45",       // <1>
  "$$title" : "Buy bread due by 2015-12-04",                        // <2>
  "description" : "Buy bread",                                      // <3>
  "category" : "Domestic",
  "subcategory" : "Shopping",
  "complete" : false,
  "atPath" : "/users/sven",
  ...
  "similarTo" : [ {                                                 // <4>
    "$$href" : "http://localhost:8080/restful/objects/TODO/46",
    "$$title" : "Buy milk due by 2015-12-04",
    "description" : "Buy milk",
    "category" : "Domestic",
    ...
  }, {
    "$$href" : "http://localhost:8080/restful/objects/TODO/47",
    "$$title" : "Buy stamps due by 2015-12-04",
    "description" : "Buy stamps",
    "category" : "Domestic",
    ...
  },
     ...
  } ],
  "dependencies" : [ ],
  "$$ro" : {                                                        // <5>
    "links" : [ ... ],
    "extensions" : { ... },
    "title" : "Buy bread due by 2015-12-04",
    "domainType" : "TODO",
    "instanceId" : "45",
    "members" : { ... }
  }
}
----
<1> hyperlink to the representation
<2> title of the domain object
<3> all the properties of the domain object (to which the caller has access), as key/value pairs
<4> contents of each collection
<5> special `$$ro` json-prop, being the normal RO Spec representation for this object

with a `Content-Type` header:

[source]
----
Content-Type: application/json;
              profile="urn:org.apache.isis/v1";repr-type="object"
----

[[_ugvro_simplified-representations_object-collection]]
== Domain Object Collection

If a domain object collection (section 17) is accessed with this profile, then the resultant representation is as
an array of elements of key/value for each referenced object, and again each element the containing the key/value
pairs of the properties of that object (a grid, again). +

In addition, the representation defined by the RO spec is also included, as a special object with a single `$$ro`
property.

For example, using the (non-ASF) http://github.com/isisaddons/isis-app-todoapp[Isis addons' todoapp], accessing
this resource:

[source]
----
http://localhost:8080/restful/objects/TODO/45/collections/similarTo
----

with an `Accept` request header of:

[source]
----
Accept: application/json;profile="urn:org.apache.isis/v1"
----

returns the following representation:

[source]
----
[                                                                   // <1>
{
  "$$href" : "http://localhost:8080/restful/objects/TODO/46",       // <2>
  "$$title" : "Buy milk due by 2015-12-04",                         // <3>
  "description" : "Buy milk",                                       // <4>
  "category" : "Domestic",
  ...
}, {
  "$$href" : "http://localhost:8080/restful/objects/TODO/47",
  "$$title" : "Buy stamps due by 2015-12-04",
  "description" : "Buy stamps",
  "category" : "Domestic",
  ...
}, {
  "$$href" : "http://localhost:8080/restful/objects/TODO/48",
  "$$title" : "Mow lawn due by 2015-12-10",
  "description" : "Mow lawn",
  "category" : "Domestic",
  ...
},
...
, {
  "$$ro" : {                                                        // <5>
    "id" : "similarTo",
    "memberType" : "collection",
    "links" : [ ... ],
    "extensions" : { ... },
    "value" : [ ... ]
  }
}
]
----
<1> returns a JSON array, not a JSON object
<2> hyperlink to the representation
<3> title of the domain object
<4> all the properties of the domain object (to which the caller has access), as key/value pairs
<5> last element is a special object with a single `$$ro` json-prop, being the normal RO Spec representation for this object

with a `Content-Type` header:

[source]
----
Content-Type: application/json;profile="urn:org.apache.isis/v1";repr-type="object-collection"
----

[[_ugvro_simplified-representations_action-invocation]]
== Action Invocation

When an action is invoked, it can return a domain object, a list, a scalar, or return nothing.

=== Returning an Object

If the action returned an object, then the domain object representation described
xref:ugvro.adoc#_ugvro_simplified-representations_domain-object[above] is returned.

For example, using the (non-ASF) http://github.com/isisaddons/isis-app-todoapp[Isis addons' todoapp], accessing
this resource:

[source]
----
http://localhost:8080/restful/objects/TODO/45/actions/updateCost/invoke
----

with an `Accept` request header of:

[source]
----
Accept: application/json;profile="urn:org.apache.isis/v1"
----

returns the following representation:

[source]
----

{
  "$$href" : "http://localhost:8080/restful/objects/TODO/45",
  "$$title" : "Buy bread due by 2015-12-04",
  "description" : "Buy bread",
  "category" : "Domestic",
  "subcategory" : "Shopping",
  "complete" : false,
  ...
  "similarTo" : [ ... ]
  ...
  "$$ro" : { ... }
}
----

with a `Content-Type` of:

[source]
----
Content-Type: application/json;profile="urn:org.apache.isis/v1";repr-type="object"
----

\... in other words no different to a representation obtained of the returned domain object directly.

=== Returning a List

On the other hand if the action returned a list (a "standalone" collection, then an array representation is returned.
This is very similar to that returned by a
xref:ugvro.adoc#_ugvro_simplified-representations_object-collection[(parented) object collection], though with a
slightly different `Content-Type` to distinguish.

For example, using the (non-ASF) http://github.com/isisaddons/isis-app-todoapp[Isis addons' todoapp], accessing
this resource:

[source]
----
http://localhost:8080/restful/services/ToDoItems/actions/notYetComplete/invoke
----

with an `Accept` request header of:

[source]
----
Accept: application/json;profile="urn:org.apache.isis/v1"
----

returns the following representation:

[source]
----
[ {
  "$$href" : "http://localhost:8080/restful/objects/TODO/45",
  "$$title" : "Buy bread due by 2015-12-04",
  "description" : "Buy bread",
  "category" : "Domestic",
  ...
}, {
  "$$href" : "http://localhost:8080/restful/objects/TODO/46",
  "$$title" : "Buy milk due by 2015-12-04",
  "description" : "Buy milk",
  "category" : "Domestic",
  ...
},
...
, {
  "$$ro" : {
    "links" : [ ... ]
    "resulttype" : "list",
    "result" : { ... }
      "value" : [ ... ],
      "links" : [ ... ],
      "extensions" : { }
    }
  }
} ]
----

with a `Content-Type` header:

[source]
----
Content-Type: application/json;profile="urn:org.apache.isis/v1";repr-type="list"
----

=== Returning Scalar/Nothing

Note that actions returning scalar values or nothing (which includes `void` actions) are not supported; for these the
regular RO spec representation will be returned.

[[_ugvro_simplified-representations_other-representations]]
== Supporting other Representations

Sometimes though you may want to extend or change the representations generated.  This might be because you want to
write a RESTful client that uses a particular library (say a Javascript library or web components) that can only handle representations in a certain form.

Or, you might want to have Apache Isis generate representations according to some other "standard", of which there are
many:

* Mike Kelly's http://stateless.co/hal_specification.html[HAL] specification
* Mike Amundsen's http://amundsen.com/media-types/collection/[Collection+JSON] specification
* Kevin Swiber's https://github.com/kevinswiber/siren[Siren] specification
* Steve Klabnik's http://jsonapi.org/[JSON API] specification
* Gregg Cainus' https://github.com/cainus/hyper-json-spec[Hyper+JSON] specification
* the W3C's https://www.w3.org/TR/json-ld/[JSON-LD] specification
* Markus Lanthaler's http://www.markus-lanthaler.com/hydra/[Hydra] specification.

A good discussion about the relative merits of several of these different hypermedia formats can be found https://groups.google.com/forum/#!msg/api-craft/NgjzQYVOE4s/EAB2jxtU_TMJ[here].

Or, of course, you may have your own internal specification that you wish to use.

Supporting any of these alternative representations can be achieved by providing a suitable implementation of
`ContentNegotiationService`.  The existing implementations (eg `ContentNegotiationServiceSimplified`) can be used as a
starting point.

[NOTE]
====
These will, admittedly, need to access the internal APIs for the Apache Isis metamodel, and you should be aware that
these are not formal API; they may change over time.  That said, they are very stable and have not changed
significantly over the last few years.
====

include::_ugvro_simplified-representations_configuration-properties.adoc[leveloffset=+1]

[[_ugvro_simplified-representations]]
= Simplified Representations
:Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR  CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
:_basedir: ../
:_imagesdir: images/

The representations defined by the RO spec are very rich and enable complex client-side applications to be built.
However, their sophistication can be an impediment to their use if one wishes to write a simple app using third-party
components that expect to consume much simpler representations.  Examples of such tools are
link:http://angular-ui.github.io/bootstrap/[Angular Bootstrap],
link:http://vitalets.github.io/angular-xeditable/[Angular XEditable],
link:https://github.com/mgcrea/angular-strap[Angular Strap].

As of `1.11.0-SNAPSHOT`, Apache Isis provides support for its own simplified representation for the most commonly-used
representations.  This is implemented using the `ContentNegotiationService` described in the
xref:ugvro.adoc#_ugvro_architecture[architecture] chapter.

[[_ugvro_simplified-representations_apache-isis-profile]]
== The Apache Isis "Profile"

The RO spec uses the standard `Accept` header for content negotiation, and defines its own "profile" for the standard
representations; these take the form:

[source]
----
Accept: application/json;profile="urn:org.restfulobjects:repr-types/xxx"
----

where "xxx" varies by resource.  The detail can be found in section 2.4.1 of the RO spec.

The Apache Isis viewer also defines its own "Isis" profile which enables the client to request simplified
representations for the most frequently accessed resources.  This is done by specifying an `Accept` header of:

[source]
----
Accept: application/json;profile="urn:org.apache.isis/v1"
----

Not every resource supports this header, but the most commonly accessed ones do.  In each case the server will set the
`Content-Type` header so that the client knows how to process the representation.

The screencast below demonstrates the feature.

video::HMSqapQDY_4[youtube,width="853px",height="480px"]

And the table below explains in a little more detail what is returned when this profile is activated.

[cols="1a,4a", options="header"]
|===

| Resource
| Description

|Domain object +
(section 14)
|The representation of a domain object is simple key/value pairs for each property.  The contents of any collections are
also eagerly returned, consisting of an array of elements of each referenced object.  Each such element contains
key/value pairs of each property (in other words, a grid of data is returned), along with special `$$href` and
`$$title` properties. +

In addition, the representation defined by the RO spec is also included, under a special `$$ro` property. +

[source]
----
Content-Type: application/json;
              profile="urn:org.apache.isis/v1";repr-type="object"
----

|Object Collection +
(section 17)
|Collections are represented as an array of elements of key/value for each referenced object, and again each element
the containing the key/value pairs of the properties of that object (a grid, again). +

In addition, the representation defined by the RO spec is also included, as a special object with a single `$$ro`
property. +

[source]
----
Content-Type: application/json;
              profile="urn:org.apache.isis/v1";repr-type="object-collection"
----

|Action invocation +
(section 19)
|If the action returned an object, then the domain object representation described above is returned. +

[source]
----
Content-Type: application/json;
              profile="urn:org.apache.isis/v1";repr-type="object"
----

If the action returned a list, then the same array representation as (parented) object collections is returned, though
with a slightly different `Content-Type` to distinguish:

[source]
----
Content-Type: application/json;
              profile="urn:org.apache.isis/v1";repr-type="list"
----

Note that actions returning scalar values or void are not supported; for these the regular RO spec representation will
be returned.

|===

[[_ugvro_simplified-representations_other-representations]]
== Supporting other Representations

Sometimes though you may want to extend or change the representations generated.  This might be because you want to
write a RESTful client that uses a particular library (say a Javascript library or web components) that can only handle representations in a certain form.

Or, you might want to have Apache Isis generate representations according to some other "standard", of which there are
many:

* Mike Kelly's http://stateless.co/hal_specification.html[HAL] specification
* Mike Amundsen's http://amundsen.com/media-types/collection/[Collection+JSON] specification
* Kevin Swiber's https://github.com/kevinswiber/siren[Siren] specification
* Steve Klabnik's http://jsonapi.org/[JSON API] specification
* Gregg Cainus' https://github.com/cainus/hyper-json-spec[Hyper+JSON] specification
* the W3C's https://www.w3.org/TR/json-ld/[JSON-LD] specification
* Markus Lanthaler's http://www.markus-lanthaler.com/hydra/[Hydra] specification.

A good discussion about the relative merits of several of these different hypermedia formats can be found https://groups.google.com/forum/#!msg/api-craft/NgjzQYVOE4s/EAB2jxtU_TMJ[here].

Or, of course, you may have your own internal specification that you wish to use.

Supporting any of these alternative representations can be achieved by providing a suitable implementation of
`ContentNegotiationService`.  The existing implementations (eg `ContentNegotiationServiceSimplified`) can be used as a
starting point.

[NOTE]
====
These will, admittedly, need to access the internal APIs for the Apache Isis metamodel, and you should be aware that
these are not formal API; they may change over time.  That said, they are very stable and have not changed
significantly over the last few years.
====

include::_ugvro_simplified-representations_configuration-properties.adoc[leveloffset=+1]


update to latest tags in tools.build

update to latest tags in tools.build

= tools.build Guide
Alex Miller
2021-06-22
:type: guides
:toc: macro
:icons: font

ifdef::env-github,env-browser[:outfilesuffix: .adoc]

toc::[]

https://github.com/clojure/tools.build[tools.build] is a library of functions for building Clojure projects. It is intended to be used in a build program to create user-invokable target functions. Also see the https://clojure.github.io/tools.build[API docs].

== Builds are programs

The philosophy behind tools.build is that your project build is inherently a program - a series of instructions to create one or more project artifacts from your project source files. We want to write this program with our favorite programming language, Clojure, and tools.build is a library of functions commonly needed for builds that can be connected together in flexible ways. Writing a build program does take a bit more code than other declarative approaches, but can be easily extended or customized far into the future, creating a build that grows with your project.

== Setup

There is no installation step - tools.build is simply a library that your build program uses. You will create an alias in your `deps.edn` that includes tools.build as a dependency and a source path to the build program. Builds are designed to be easily executed as a project "tool" in the Clojure CLI (with -T). In the Clojure CLI, "tools" are programs that provide functionality and do not use your project deps or classpath. Tools executed with `-T:an-alias` remove all project deps and paths, add `"."` as a path, and include any other deps or paths as defined in `:an-alias`.

As such, you will need an alias in your deps.edn that defines the build classpath and includes the path to your build source, for example:

[source,clojure]
----
{:paths ["src"] ;; project paths
 :deps {}       ;; project deps

 :aliases
 {;; Run with clj -T:build function-in-build
  :build {:deps {io.github.clojure/tools.build {:git/tag "TAG" :git/sha "SHA"}}
          :ns-default build}}}
----

Find the most recent TAG and SHA to use at https://github.com/clojure/tools.build#release-information.

[NOTE]
====
The git dep and Clojure CLI examples in this guide assume the use of Clojure CLI 1.10.3.933 or higher.
====

As mentioned above, running a tool with -T will create a classpath that does not include the project :paths and :deps. Using `-T:build` will use only the `:paths` and `:deps` from the `:build` alias. The root deps.edn is still included, which will pull in Clojure as well (but it would also come in as a dependency of tools.build). The `:paths` are not specified here, so no additional paths are added, however, `-T` includes the project root `"."` as a path by default.

So executing `clj -T:build jar` will use an effective classpath here of:

* `"."` (added by -T)
* org.clojure/clojure (from the root deps.edn `:deps`) and transitive deps
* org.clojure/tools.build (from the `:build` alias `:deps`) and transitive deps

The `:ns-default` specifies the default Clojure namespace to find the function specified on the classpath. Because the only local path is the default `"."`, we should expect to find the build program at `build.clj` in the root of our project. Note that the path roots (via the `:build` alias `:paths`) and the namespace of the build program itself relative to those paths roots are fully under your control. You may wish to put them in a subdirectory of your project too.

And then finally, on the command line we specify the function to run in the build, here `jar`. That function will be executed in the `build` namespace, and passed a map built using the same arg passing style as `-X` - args are provided as alternating keys and values.

The remainder of this guide demonstrates individual common use cases and how to satisfy them with tools.build programs.

== Source library jar build

The most common Clojure build creates a jar file containing Clojure source code. To do this with tools.build we'll use the following tasks:

* `create-basis` - to create a project basis
* `copy-dir` - to copy Clojure source and resources into a working dir
* `write-pom` - to write a pom file in the working dir
* `jar` - to jar up the working dir into a jar file

The build.clj will look like this:

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))

(defn clean [_]
  (b/delete {:path "target"}))

(defn jar [_]
  (b/write-pom {:class-dir class-dir
                :lib lib
                :version version
                :basis basis
                :src-dirs ["src"]})
  (b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})
  (b/jar {:class-dir class-dir
          :jar-file jar-file}))
----

Some things to notice:

* This is just normal Clojure code - you can load this namespace in your editor and develop it interactively at the REPL.
* As a single-purpose program, it's fine to build shared data in the set of vars at the top.
* We are choosing to build in the "target" directory and assemble the jar contents in "target/classes" but there is nothing special about these paths - it is fully in your control. Also, we've repeated those paths and others in multiple places here but you can remove that duplication to the extent that feels right.
* We've used the tools.build task functions to assemble larger functions like `build/jar` for the user to invoke. These functions take a parameter map and we've chosen not to provide any configurable parameters here, but you could!

The deps.edn file will look like this:

[source,clojure]
----
{:paths ["src"]
 :aliases
 {:build {:deps {io.github.clojure/tools.build {:git/tag "TAG" :git/sha "SHA"}}
          :ns-default build}}}
----

And then you can run this build with:

[source,shell]
----
clj -T:build clean
clj -T:build jar
----

We expect to be able to do these both together on the command line but that is a work in progress.

== Compiled uberjar application build

When preparing an application, it is common to compile the full app + libs and assemble the entire thing as a single uberjar.

It is important that your main Clojure namespace should have `(:gen-class)`, for example:

[source,clojure]
----
(ns my.lib.main
  ;; any :require and/or :import clauses
  (:gen-class))
----

And that namespace should have a function like:

[source,clojure]
----
(defn -main [& args]
  (do-stuff))
----

An example build for a compiled uberjar will look like this:

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def uber-file (format "target/%s-%s-standalone.jar" (name lib) version))

(defn clean [_]
  (b/delete {:path "target"}))

(defn uber [_]
  (clean nil)
  (b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})
  (b/compile-clj {:basis basis
                  :src-dirs ["src"]
                  :class-dir class-dir})
  (b/uber {:class-dir class-dir
           :uber-file uber-file
           :basis basis
           :main 'my.lib.main}))
----

The deps.edn and build execution will look the same as the prior example.

You can create the uber jar build with:

[source]
----
clj -T:build uber
----

The output of this build will be an uberjar at `target/lib1-1.2.100-standalone.jar`. That jar contains both a compiled version of this project and all of its dependencies. The uberjar will have a manifest referring to the `my.lib.main` namespace (which should have a `-main` method) and can be invoked like this:

[source]
----
java -jar target/lib1-1.2.100-standalone.jar
----

== Parameterized builds

In the builds above we did not parameterize any aspect of the build, just chose which functions to call. You may find that it's useful to parameterize your builds to differentiate dev/qa/prod, or version, or some other factor. To account for function chaining at the command line, it is advisable to establish the common set of parameters to use across your build functions and have each function pass the parameters along.

For example, consider a parameterization that includes an extra set of dev resources to set a local developer environment. We'll use a simple `:env :dev` kv pair to indicate this:

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))
(def copy-srcs ["src" "resources"])

(defn clean [params]
  (b/delete {:path "target"})
  params)

(defn jar [{:keys [env] :as params}]
  (let [srcs (if (= env :dev) (cons "dev-resources" copy-srcs) copy-srcs)]
    (b/write-pom {:class-dir class-dir
                  :lib lib
                  :version version
                  :basis basis
                  :src-dirs ["src"]})
    (b/copy-dir {:src-dirs srcs
                 :target-dir class-dir})
    (b/jar {:class-dir class-dir
            :jar-file jar-file})
    params))
----

The other aspects of deps.edn and invocation remain the same.

Invocation that activates :dev environment will look like this:

[source,shell]
----
clj -T:build jar :env :dev
----

The kv params are passed to the `jar` function.

== Mixed Java / Clojure build

A common case that occurs is needing to introduce a Java implementation class or two into a mostly Clojure project. In this case, you need to compile the Java classes and include them with your Clojure source. In this setup, we'll assume that your Clojure source is in `src/` and Java source is in `java/` (where you actually put these is of course up to you).

This build creates a jar with classes compiled from Java sources and your Clojure sources.

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))

(defn clean [_]
  (b/delete {:path "target"}))

(defn compile [_]
  (b/javac {:src-dirs ["java"]
            :class-dir class-dir
            :basis basis
            :javac-opts ["-source" "8" "-target" "8"]}))

(defn jar [_]
  (compile nil)
  (b/write-pom {:class-dir class-dir
                :lib lib
                :version version
                :basis basis
                :src-dirs ["src"]})
  (b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})
  (b/jar {:class-dir class-dir
          :jar-file jar-file}))
----

The `compile` task here can also be used as the <<deps_and_cli#prep_libs,prep task>> for this lib.

== Task documentation

See the https://clojure.github.io/tools.build[API docs] for detailed task documentation.

= tools.build Guide
Alex Miller
2021-06-22
:type: guides
:toc: macro
:icons: font

ifdef::env-github,env-browser[:outfilesuffix: .adoc]

toc::[]

https://github.com/clojure/tools.build[tools.build] is a library of functions for building Clojure projects. It is intended to be used in a build program to create user-invokable target functions. Also see the https://clojure.github.io/tools.build[API docs].

== Builds are programs

The philosophy behind tools.build is that your project build is inherently a program - a series of instructions to create one or more project artifacts from your project source files. We want to write this program with our favorite programming language, Clojure, and tools.build is a library of functions commonly needed for builds that can be connected together in flexible ways. Writing a build program does take a bit more code than other declarative approaches, but can be easily extended or customized far into the future, creating a build that grows with your project.

== Setup

There is no installation step - tools.build is simply a library that your build program uses. You will create an alias in your `deps.edn` that includes tools.build as a dependency and a source path to the build program. Builds are designed to be easily executed as a project "tool" in the Clojure CLI (with -T). In the Clojure CLI, "tools" are programs that provide functionality and do not use your project deps or classpath. Tools executed with `-T:an-alias` remove all project deps and paths, add `"."` as a path, and include any other deps or paths as defined in `:an-alias`.

As such, you will need an alias in your deps.edn that defines the build classpath and includes the path to your build source, for example:

[source,clojure]
----
{:paths ["src"] ;; project paths
 :deps {}       ;; project deps

 :aliases
 {;; Run with clj -T:build function-in-build
  :build {:deps {io.github.clojure/tools.build {:tag "TAG" :sha "SHA"}}
          :ns-default build}}}
----

Find the most recent TAG and SHA to use at https://github.com/clojure/tools.build#release-information.

[NOTE]
====
The git dep and Clojure CLI examples in this guide assume the use of Clojure CLI 1.10.3.933 or higher.
====

As mentioned above, running a tool with -T will create a classpath that does not include the project :paths and :deps. Using `-T:build` will use only the `:paths` and `:deps` from the `:build` alias. The root deps.edn is still included, which will pull in Clojure as well (but it would also come in as a dependency of tools.build). The `:paths` are not specified here, so no additional paths are added, however, `-T` includes the project root `"."` as a path by default.

So executing `clj -T:build jar` will use an effective classpath here of:

* `"."` (added by -T)
* org.clojure/clojure (from the root deps.edn `:deps`) and transitive deps
* org.clojure/tools.build (from the `:build` alias `:deps`) and transitive deps

The `:ns-default` specifies the default Clojure namespace to find the function specified on the classpath. Because the only local path is the default `"."`, we should expect to find the build program at `build.clj` in the root of our project. Note that the path roots (via the `:build` alias `:paths`) and the namespace of the build program itself relative to those paths roots are fully under your control. You may wish to put them in a subdirectory of your project too.

And then finally, on the command line we specify the function to run in the build, here `jar`. That function will be executed in the `build` namespace, and passed a map built using the same arg passing style as `-X` - args are provided as alternating keys and values.

The remainder of this guide demonstrates individual common use cases and how to satisfy them with tools.build programs.

== Source library jar build

The most common Clojure build creates a jar file containing Clojure source code. To do this with tools.build we'll use the following tasks:

* `create-basis` - to create a project basis
* `copy-dir` - to copy Clojure source and resources into a working dir
* `write-pom` - to write a pom file in the working dir
* `jar` - to jar up the working dir into a jar file

The build.clj will look like this:

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))

(defn clean [_]
  (b/delete {:path "target"}))

(defn jar [_]
  (b/write-pom {:class-dir class-dir
                :lib lib
                :version version
                :basis basis
                :src-dirs ["src"]})
  (b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})
  (b/jar {:class-dir class-dir
          :jar-file jar-file}))
----

Some things to notice:

* This is just normal Clojure code - you can load this namespace in your editor and develop it interactively at the REPL.
* As a single-purpose program, it's fine to build shared data in the set of vars at the top.
* We are choosing to build in the "target" directory and assemble the jar contents in "target/classes" but there is nothing special about these paths - it is fully in your control. Also, we've repeated those paths and others in multiple places here but you can remove that duplication to the extent that feels right.
* We've used the tools.build task functions to assemble larger functions like `build/jar` for the user to invoke. These functions take a parameter map and we've chosen not to provide any configurable parameters here, but you could!

The deps.edn file will look like this:

[source,clojure]
----
{:paths ["src"]
 :aliases
 {:build {:deps {io.github.clojure/tools.build {:tag "TAG" :sha "SHA"}}
          :ns-default build}}}
----

And then you can run this build with:

[source,shell]
----
clj -T:build clean
clj -T:build jar
----

We expect to be able to do these both together on the command line but that is a work in progress.

== Compiled uberjar application build

When preparing an application, it is common to compile the full app + libs and assemble the entire thing as a single uberjar.

It is important that your main Clojure namespace should have `(:gen-class)`, for example:

[source,clojure]
----
(ns my.lib.main
  ;; any :require and/or :import clauses
  (:gen-class))
----

And that namespace should have a function like:

[source,clojure]
----
(defn -main [& args]
  (do-stuff))
----

An example build for a compiled uberjar will look like this:

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def uber-file (format "target/%s-%s-standalone.jar" (name lib) version))

(defn clean [_]
  (b/delete {:path "target"}))

(defn uber [_]
  (clean nil)
  (b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})
  (b/compile-clj {:basis basis
                  :src-dirs ["src"]
                  :class-dir class-dir})
  (b/uber {:class-dir class-dir
           :uber-file uber-file
           :basis basis
           :main 'my.lib.main}))
----

The deps.edn and build execution will look the same as the prior example.

You can create the uber jar build with:

[source]
----
clj -T:build uber
----

The output of this build will be an uberjar at `target/lib1-1.2.100-standalone.jar`. That jar contains both a compiled version of this project and all of its dependencies. The uberjar will have a manifest referring to the `my.lib.main` namespace (which should have a `-main` method) and can be invoked like this:

[source]
----
java -jar target/lib1-1.2.100-standalone.jar
----

== Parameterized builds

In the builds above we did not parameterize any aspect of the build, just chose which functions to call. You may find that it's useful to parameterize your builds to differentiate dev/qa/prod, or version, or some other factor. To account for function chaining at the command line, it is advisable to establish the common set of parameters to use across your build functions and have each function pass the parameters along.

For example, consider a parameterization that includes an extra set of dev resources to set a local developer environment. We'll use a simple `:env :dev` kv pair to indicate this:

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))
(def copy-srcs ["src" "resources"])

(defn clean [params]
  (b/delete {:path "target"})
  params)

(defn jar [{:keys [env] :as params}]
  (let [srcs (if (= env :dev) (cons "dev-resources" copy-srcs) copy-srcs)]
    (b/write-pom {:class-dir class-dir
                  :lib lib
                  :version version
                  :basis basis
                  :src-dirs ["src"]})
    (b/copy-dir {:src-dirs srcs
                 :target-dir class-dir})
    (b/jar {:class-dir class-dir
            :jar-file jar-file})
    params))
----

The other aspects of deps.edn and invocation remain the same.

Invocation that activates :dev environment will look like this:

[source,shell]
----
clj -T:build jar :env :dev
----

The kv params are passed to the `jar` function.

== Mixed Java / Clojure build

A common case that occurs is needing to introduce a Java implementation class or two into a mostly Clojure project. In this case, you need to compile the Java classes and include them with your Clojure source. In this setup, we'll assume that your Clojure source is in `src/` and Java source is in `java/` (where you actually put these is of course up to you).

This build creates a jar with classes compiled from Java sources and your Clojure sources.

[source,clojure]
----
(ns build
  (:require [clojure.tools.build.api :as b]))

(def lib 'my/lib1)
(def version (format "1.2.%s" (b/git-count-revs nil)))
(def class-dir "target/classes")
(def basis (b/create-basis {:project "deps.edn"}))
(def jar-file (format "target/%s-%s.jar" (name lib) version))

(defn clean [_]
  (b/delete {:path "target"}))

(defn compile [_]
  (b/javac {:src-dirs ["java"]
            :class-dir class-dir
            :basis basis
            :javac-opts ["-source" "8" "-target" "8"]}))

(defn jar [_]
  (compile nil)
  (b/write-pom {:class-dir class-dir
                :lib lib
                :version version
                :basis basis
                :src-dirs ["src"]})
  (b/copy-dir {:src-dirs ["src" "resources"]
               :target-dir class-dir})
  (b/jar {:class-dir class-dir
          :jar-file jar-file}))
----

The `compile` task here can also be used as the <<deps_and_cli#prep_libs,prep task>> for this lib.

== Task documentation

See the https://clojure.github.io/tools.build[API docs] for detailed task documentation.


turned link into image.

turned link into image.

= rise_of_mutants_project
:author:
:revnumber:
:revdate: 2016/03/17 20:48
:relfileprefix: ../
:imagesdir: ..
ifdef::env-github,env-browser[:outfilesuffix: .adoc]

Rise of Mutants project by BigBootsTeam.

Project is hosted here: link:https://code.google.com/p/rise-of-mutants/source/list[https://code.google.com/p/rise-of-mutants/source/list]

Features:

- World Editor is Blender (export to Ogre scene).

- Entity System.

- Ready Framework.

- Ready Gameplay.

- Model Viewer tool.

- LightBlow Shader is used.

ScreenShot: image:https://i.imgur.com/uFRw4.jpg[https://i.imgur.com/uFRw4.jpg]

Video:

image::jme3/riseofmutants3.jpg[youtu.be/_aFSEJlISyI,width="",height="",link="https://youtu.be/_aFSEJlISyI"]

= rise_of_mutants_project
:author:
:revnumber:
:revdate: 2016/03/17 20:48
:relfileprefix: ../
:imagesdir: ..
ifdef::env-github,env-browser[:outfilesuffix: .adoc]

Rise of Mutants project by BigBootsTeam.

Project is hosted here: link:https://code.google.com/p/rise-of-mutants/source/list[https://code.google.com/p/rise-of-mutants/source/list]

Features:

- World Editor is Blender (export to Ogre scene).

- Entity System.

- Ready Framework.

- Ready Gameplay.

- Model Viewer tool.

- LightBlow Shader is used.

ScreenShot: link:https://i.imgur.com/uFRw4.jpg[https://i.imgur.com/uFRw4.jpg]

Video:

image::jme3/riseofmutants3.jpg[youtu.be/_aFSEJlISyI,width="",height="",link="https://youtu.be/_aFSEJlISyI"]


shorten topic

shorten topic


Update 2016-09-11-Going-Vegan.adoc

Update 2016-09-11-Going-Vegan.adoc

= Going Vegan!

:hp-tags: [vegan]

My name is Roxanne Joncas. I am Canadian living in Kiel, Germany. For the past two years, I have been a "vegepreferian" (term coined by my friend Wayne) that indulges in minimalism. I have decided to make my lifestyle a more sensible, mindful, and conscious one. That is why I have decided to become vegan. I will be posting my journey on my https://www.youtube.com/channel/UC3u3YZ35NU1Zl3zxRH3d7OA[YouTube Channel].

Join in on the fun, follow my journey or become a vegan and share your though
ts/ideas!

++++
<iframe width="560" height="315" src="https://www.youtube.com/embed/jZylH73e-lA" frameborder="0" allowfullscreen></iframe>
++++

= Going Vegan!

:hp-tags: [vegan]

My name is Roxanne Joncas. I am Canadian living in Kiel, Germany. For the past two years, I have been a "vegepreferian" (term coined by my friend Wayne) that indulges in minimalism. I have decided to make my lifestyle a more sensible, mindful, and conscious one. That is why I have decided to become vegan. I will be posting my journey on my https://www.youtube.com/channel/UC3u3YZ35NU1Zl3zxRH3d7OA[YouTube Channel].

Join in on the fun, follow my journey or become a vegan and share your thoughts/ideas!


Camel-AS2: Improve NOTE section

Camel-AS2: Improve NOTE section

[[as2-component]]
= AS2 Component

*Since Camel 2.22*

// HEADER START
*Both producer and consumer is supported*
// HEADER END

The AS2 component provides transport of EDI messages using the HTTP transfer protocol
as specified in https://tools.ietf.org/html/rfc4130[RFC4130].

[NOTE]
====
This component is currently a work in progress. Expect URI options and path and query parameters to change in future versions of this component.
====

Maven users will need to add the following dependency to their pom.xml
for this component:

[source,xml]
----
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-as2</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>
----

== URI format

[source]
----
as2://apiName/methodName
----

apiName can be one of:

* client
* server

== AS2 Options

// component options: START
The AS2 component supports 4 options, which are listed below.

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *configuration* (common) | To use the shared configuration |  | AS2Configuration
| *basicPropertyBinding* (advanced) | Whether the component should use basic property binding (Camel 2.x) or the newer property binding with additional capabilities | false | boolean
| *lazyStartProducer* (producer) | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. | false | boolean
| *bridgeErrorHandler* (consumer) | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | boolean
|===
// component options: END

// endpoint options: START
The AS2 endpoint is configured using URI syntax:

----
as2:apiName/methodName
----

with the following path and query parameters:

=== Path Parameters (2 parameters):

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *apiName* | *Required* What kind of operation to perform |  | AS2ApiName
| *methodName* | *Required* What sub operation to use for the selected operation |  | String
|===

=== Query Parameters (49 parameters):

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *as2From* (common) | The value of the AS2From header of AS2 message. |  | String
| *as2MessageStructure* (common) | The structure of AS2 Message. One of: PLAIN - No encryption, no signature, SIGNED - No encryption, signature, ENCRYPTED - Encryption, no signature, ENCRYPTED_SIGNED - Encryption, signature |  | AS2MessageStructure
| *as2To* (common) | The value of the AS2To header of AS2 message. |  | String
| *as2Version* (common) | The version of the AS2 protocol. | 1.1 | String
| *clientFqdn* (common) | The Client Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *compressionAlgorithm* (common) | The algorithm used to compress EDI message. |  | AS2CompressionAlgorithm
| *decryptingPrivateKey* (common) | The key used to encrypt the EDI message. |  | PrivateKey
| *dispositionNotificationTo* (common) | The value of the Disposition-Notification-To header. Assigning a value to this parameter requests a message disposition notification (MDN) for the AS2 message. |  | String
| *ediMessageTransferEncoding* (common) | The transfer encoding of EDI message. |  | String
| *ediMessageType* (common) | The content type of EDI message. One of application/edifact, application/edi-x12, application/edi-consent |  | ContentType
| *encryptingAlgorithm* (common) | The algorithm used to encrypt EDI message. |  | AS2EncryptionAlgorithm
| *encryptingCertificateChain* (common) | The chain of certificates used to encrypt EDI message. |  | Certificate[]
| *from* (common) | The value of the From header of AS2 message. |  | String
| *inBody* (common) | Sets the name of a parameter to be passed in the exchange In Body |  | String
| *mdnMessageTemplate* (common) | The template used to format MDN message |  | String
| *requestUri* (common) | The request URI of EDI message. | / | String
| *server* (common) | The value included in the Server message header identifying the AS2 Server. | Camel AS2 Server Endpoint | String
| *serverFqdn* (common) | The Server Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *serverPortNumber* (common) | The port number of server. |  | Integer
| *signedReceiptMicAlgorithms* (common) | The list of algorithms, in order of preference, requested to generate a message integrity check (MIC) returned in message dispostion notification (MDN) |  | String[]
| *signingAlgorithm* (common) | The algorithm used to sign EDI message. |  | AS2SignatureAlgorithm
| *signingCertificateChain* (common) | The chain of certificates used to sign EDI message. |  | Certificate[]
| *signingPrivateKey* (common) | The key used to sign the EDI message. |  | PrivateKey
| *subject* (common) | The value of Subject header of AS2 message. |  | String
| *targetHostname* (common) | The host name (IP or DNS name) of target host. |  | String
| *targetPortNumber* (common) | The port number of target host. -1 indicates the scheme default port. |  | Integer
| *userAgent* (common) | The value included in the User-Agent message header identifying the AS2 user agent. | Camel AS2 Client Endpoint | String
| *bridgeErrorHandler* (consumer) | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | boolean
| *sendEmptyMessageWhenIdle* (consumer) | If the polling consumer did not poll any files, you can enable this option to send an empty message (no body) instead. | false | boolean
| *exceptionHandler* (consumer) | To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. |  | ExceptionHandler
| *exchangePattern* (consumer) | Sets the exchange pattern when the consumer creates an exchange. |  | ExchangePattern
| *pollStrategy* (consumer) | A pluggable org.apache.camel.PollingConsumerPollingStrategy allowing you to provide your custom implementation to control error handling usually occurred during the poll operation before an Exchange have been created and being routed in Camel. |  | PollingConsumerPollStrategy
| *lazyStartProducer* (producer) | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. | false | boolean
| *basicPropertyBinding* (advanced) | Whether the endpoint should use basic property binding (Camel 2.x) or the newer property binding with additional capabilities | false | boolean
| *synchronous* (advanced) | Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). | false | boolean
| *backoffErrorThreshold* (scheduler) | The number of subsequent error polls (failed due some error) that should happen before the backoffMultipler should kick-in. |  | int
| *backoffIdleThreshold* (scheduler) | The number of subsequent idle polls that should happen before the backoffMultipler should kick-in. |  | int
| *backoffMultiplier* (scheduler) | To let the scheduled polling consumer backoff if there has been a number of subsequent idles/errors in a row. The multiplier is then the number of polls that will be skipped before the next actual attempt is happening again. When this option is in use then backoffIdleThreshold and/or backoffErrorThreshold must also be configured. |  | int
| *delay* (scheduler) | Milliseconds before the next poll. You can also specify time values using units, such as 60s (60 seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour). | 500 | long
| *greedy* (scheduler) | If greedy is enabled, then the ScheduledPollConsumer will run immediately again, if the previous run polled 1 or more messages. | false | boolean
| *initialDelay* (scheduler) | Milliseconds before the first poll starts. You can also specify time values using units, such as 60s (60 seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour). | 1000 | long
| *repeatCount* (scheduler) | Specifies a maximum limit of number of fires. So if you set it to 1, the scheduler will only fire once. If you set it to 5, it will only fire five times. A value of zero or negative means fire forever. | 0 | long
| *runLoggingLevel* (scheduler) | The consumer logs a start/complete log line when it polls. This option allows you to configure the logging level for that. | TRACE | LoggingLevel
| *scheduledExecutorService* (scheduler) | Allows for configuring a custom/shared thread pool to use for the consumer. By default each consumer has its own single threaded thread pool. |  | ScheduledExecutorService
| *scheduler* (scheduler) | To use a cron scheduler from either camel-spring or camel-quartz component | none | String
| *schedulerProperties* (scheduler) | To configure additional properties when using a custom scheduler or any of the Quartz, Spring based scheduler. |  | Map
| *startScheduler* (scheduler) | Whether the scheduler should be auto started. | true | boolean
| *timeUnit* (scheduler) | Time unit for initialDelay and delay options. | MILLISECONDS | TimeUnit
| *useFixedDelay* (scheduler) | Controls if fixed delay or fixed rate is used. See ScheduledExecutorService in JDK for details. | true | boolean
|===
// endpoint options: END
// spring-boot-auto-configure options: START
== Spring Boot Auto-Configuration

When using Spring Boot make sure to use the following Maven dependency to have support for auto configuration:

[source,xml]
----
<dependency>
  <groupId>org.apache.camel.springboot</groupId>
  <artifactId>camel-as2-starter</artifactId>
  <version>x.x.x</version>
  <!-- use the same version as your Camel core version -->
</dependency>
----

The component supports 32 options, which are listed below.

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *camel.component.as2.basic-property-binding* | Whether the component should use basic property binding (Camel 2.x) or the newer property binding with additional capabilities | false | Boolean
| *camel.component.as2.bridge-error-handler* | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | Boolean
| *camel.component.as2.configuration.api-name* | What kind of operation to perform |  | AS2ApiName
| *camel.component.as2.configuration.as2-from* | The value of the AS2From header of AS2 message. |  | String
| *camel.component.as2.configuration.as2-message-structure* | The structure of AS2 Message. One of: PLAIN - No encryption, no signature, SIGNED - No encryption, signature, ENCRYPTED - Encryption, no signature, ENCRYPTED_SIGNED - Encryption, signature |  | AS2MessageStructure
| *camel.component.as2.configuration.as2-to* | The value of the AS2To header of AS2 message. |  | String
| *camel.component.as2.configuration.as2-version* | The version of the AS2 protocol. | 1.1 | String
| *camel.component.as2.configuration.client-fqdn* | The Client Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *camel.component.as2.configuration.compression-algorithm* | The algorithm used to compress EDI message. |  | AS2CompressionAlgorithm
| *camel.component.as2.configuration.decrypting-private-key* | The key used to encrypt the EDI message. |  | PrivateKey
| *camel.component.as2.configuration.disposition-notification-to* | The value of the Disposition-Notification-To header. Assigning a value to this parameter requests a message disposition notification (MDN) for the AS2 message. |  | String
| *camel.component.as2.configuration.edi-message-transfer-encoding* | The transfer encoding of EDI message. |  | String
| *camel.component.as2.configuration.edi-message-type* | The content type of EDI message. One of application/edifact, application/edi-x12, application/edi-consent |  | ContentType
| *camel.component.as2.configuration.encrypting-algorithm* | The algorithm used to encrypt EDI message. |  | AS2EncryptionAlgorithm
| *camel.component.as2.configuration.encrypting-certificate-chain* | The chain of certificates used to encrypt EDI message. |  | Certificate[]
| *camel.component.as2.configuration.from* | The value of the From header of AS2 message. |  | String
| *camel.component.as2.configuration.mdn-message-template* | The template used to format MDN message |  | String
| *camel.component.as2.configuration.method-name* | What sub operation to use for the selected operation |  | String
| *camel.component.as2.configuration.request-uri* | The request URI of EDI message. | / | String
| *camel.component.as2.configuration.server* | The value included in the Server message header identifying the AS2 Server. | Camel AS2 Server Endpoint | String
| *camel.component.as2.configuration.server-fqdn* | The Server Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *camel.component.as2.configuration.server-port-number* | The port number of server. |  | Integer
| *camel.component.as2.configuration.signed-receipt-mic-algorithms* | The list of algorithms, in order of preference, requested to generate a message integrity check (MIC) returned in message dispostion notification (MDN) |  | String[]
| *camel.component.as2.configuration.signing-algorithm* | The algorithm used to sign EDI message. |  | AS2SignatureAlgorithm
| *camel.component.as2.configuration.signing-certificate-chain* | The chain of certificates used to sign EDI message. |  | Certificate[]
| *camel.component.as2.configuration.signing-private-key* | The key used to sign the EDI message. |  | PrivateKey
| *camel.component.as2.configuration.subject* | The value of Subject header of AS2 message. |  | String
| *camel.component.as2.configuration.target-hostname* | The host name (IP or DNS name) of target host. |  | String
| *camel.component.as2.configuration.target-port-number* | The port number of target host. -1 indicates the scheme default port. |  | Integer
| *camel.component.as2.configuration.user-agent* | The value included in the User-Agent message header identifying the AS2 user agent. | Camel AS2 Client Endpoint | String
| *camel.component.as2.enabled* | Whether to enable auto configuration of the as2 component. This is enabled by default. |  | Boolean
| *camel.component.as2.lazy-start-producer* | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. | false | Boolean
|===
// spring-boot-auto-configure options: END

== Client Endpoints:

Client endpoints use the endpoint prefix *`client`* followed by the name of a method
and associated options described next. The endpoint URI MUST contain the prefix *`client`*.

[source]
----
as2://client/method?[options]
----

Endpoint options that are not mandatory are denoted by *[]*. When there
are no mandatory options for an endpoint, one of the set of *[]* options
MUST be provided. Producer endpoints can also use a special
option *`inBody`* that in turn should contain the name of the endpoint
option whose value will be contained in the Camel Exchange In message.

Any of the endpoint options can be provided in either the endpoint URI,
or dynamically in a message header. The message header name must be of
the format *`CamelAS2.<option>`*. Note that the *`inBody`* option
overrides message header, i.e. the endpoint
option *`inBody=option`* would override a *`CamelAS2.option`* header.

If a value is not provided for the option *defaultRequest* either in the
endpoint URI or in a message header, it will be assumed to be `null`.
Note that the `null` value will only be used if other options do not
satisfy matching endpoints.

In case of AS2 API errors the endpoint will throw a
RuntimeCamelException with a
*org.apache.http.HttpException* derived exception
cause.

[width="100%",cols="10%,10%,70%",options="header"]
|===
|Method |Options |Result Body Type

|send |ediMessage, requestUri, subject, from, as2From, as2To, as2MessageStructure, ediMessageContentType, ediMessageTransferEncoding, dispositionNotificationTo, signedReceiptMicAlgorithms |org.apache.http.protocol.HttpCoreContext
|===

URI Options for _client_

[width="100%",cols="10%,90%",options="header"]
|===
|Name |Type

|ediMessage |String

|requestUri |String

|subject |String

|from |String

|as2From |String

|as2To |String

|as2MessageStructure |org.apache.camel.component.as2.api.AS2MessageStructure

|ediMessageContentType |String

|ediMessageTransferEncoding |String

|dispositionNotificationTo |String

|signedReceiptMicAlgorithms |String[]
|===

== Server Endpoints:

Server endpoints use the endpoint prefix *`server`* followed by the name of a method
and associated options described next. The endpoint URI MUST contain the prefix *`server`*.

[source]
----
as2://server/method?[options]
----

Endpoint options that are not mandatory are denoted by *[]*. When there
are no mandatory options for an endpoint, one of the set of *[]* options
MUST be provided. Producer endpoints can also use a special
option *`inBody`* that in turn should contain the name of the endpoint
option whose value will be contained in the Camel Exchange In message.

Any of the endpoint options can be provided in either the endpoint URI,
or dynamically in a message header. The message header name must be of
the format *`CamelAS2.<option>`*. Note that the *`inBody`* option
overrides message header, i.e. the endpoint
option *`inBody=option`* would override a *`CamelAS2.option`* header.

If a value is not provided for the option *defaultRequest* either in the
endpoint URI or in a message header, it will be assumed to be `null`.
Note that the `null` value will only be used if other options do not
satisfy matching endpoints.

In case of AS2 API errors the endpoint will throw a
RuntimeCamelException with a
*org.apache.http.HttpException* derived exception
cause.

[width="100%",cols="10%,10%,70%",options="header"]
|===
|Method |Options |Result Body Type

|listen |requestUriPattern |org.apache.http.protocol.HttpCoreContext
|===

URI Options for _server_

[width="100%",cols="10%,90%",options="header"]
|===
|Name |Type

|requestUriPattern |String
|===

[[as2-component]]
= AS2 Component

*Since Camel 2.22*

// HEADER START
*Both producer and consumer is supported*
// HEADER END

The AS2 component provides transport of EDI messages using the HTTP transfer protocol
as specified in https://tools.ietf.org/html/rfc4130[RFC4130].

NOTE: This component is currently a work in progress. Expect URI options and path and query parameters to change in future versions of this component.

Maven users will need to add the following dependency to their pom.xml
for this component:

[source,xml]
----
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-as2</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>
----

== URI format

[source]
----
as2://apiName/methodName
----

apiName can be one of:

* client
* server

== AS2 Options

// component options: START
The AS2 component supports 4 options, which are listed below.

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *configuration* (common) | To use the shared configuration |  | AS2Configuration
| *basicPropertyBinding* (advanced) | Whether the component should use basic property binding (Camel 2.x) or the newer property binding with additional capabilities | false | boolean
| *lazyStartProducer* (producer) | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. | false | boolean
| *bridgeErrorHandler* (consumer) | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | boolean
|===
// component options: END

// endpoint options: START
The AS2 endpoint is configured using URI syntax:

----
as2:apiName/methodName
----

with the following path and query parameters:

=== Path Parameters (2 parameters):

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *apiName* | *Required* What kind of operation to perform |  | AS2ApiName
| *methodName* | *Required* What sub operation to use for the selected operation |  | String
|===

=== Query Parameters (49 parameters):

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *as2From* (common) | The value of the AS2From header of AS2 message. |  | String
| *as2MessageStructure* (common) | The structure of AS2 Message. One of: PLAIN - No encryption, no signature, SIGNED - No encryption, signature, ENCRYPTED - Encryption, no signature, ENCRYPTED_SIGNED - Encryption, signature |  | AS2MessageStructure
| *as2To* (common) | The value of the AS2To header of AS2 message. |  | String
| *as2Version* (common) | The version of the AS2 protocol. | 1.1 | String
| *clientFqdn* (common) | The Client Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *compressionAlgorithm* (common) | The algorithm used to compress EDI message. |  | AS2CompressionAlgorithm
| *decryptingPrivateKey* (common) | The key used to encrypt the EDI message. |  | PrivateKey
| *dispositionNotificationTo* (common) | The value of the Disposition-Notification-To header. Assigning a value to this parameter requests a message disposition notification (MDN) for the AS2 message. |  | String
| *ediMessageTransferEncoding* (common) | The transfer encoding of EDI message. |  | String
| *ediMessageType* (common) | The content type of EDI message. One of application/edifact, application/edi-x12, application/edi-consent |  | ContentType
| *encryptingAlgorithm* (common) | The algorithm used to encrypt EDI message. |  | AS2EncryptionAlgorithm
| *encryptingCertificateChain* (common) | The chain of certificates used to encrypt EDI message. |  | Certificate[]
| *from* (common) | The value of the From header of AS2 message. |  | String
| *inBody* (common) | Sets the name of a parameter to be passed in the exchange In Body |  | String
| *mdnMessageTemplate* (common) | The template used to format MDN message |  | String
| *requestUri* (common) | The request URI of EDI message. | / | String
| *server* (common) | The value included in the Server message header identifying the AS2 Server. | Camel AS2 Server Endpoint | String
| *serverFqdn* (common) | The Server Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *serverPortNumber* (common) | The port number of server. |  | Integer
| *signedReceiptMicAlgorithms* (common) | The list of algorithms, in order of preference, requested to generate a message integrity check (MIC) returned in message dispostion notification (MDN) |  | String[]
| *signingAlgorithm* (common) | The algorithm used to sign EDI message. |  | AS2SignatureAlgorithm
| *signingCertificateChain* (common) | The chain of certificates used to sign EDI message. |  | Certificate[]
| *signingPrivateKey* (common) | The key used to sign the EDI message. |  | PrivateKey
| *subject* (common) | The value of Subject header of AS2 message. |  | String
| *targetHostname* (common) | The host name (IP or DNS name) of target host. |  | String
| *targetPortNumber* (common) | The port number of target host. -1 indicates the scheme default port. |  | Integer
| *userAgent* (common) | The value included in the User-Agent message header identifying the AS2 user agent. | Camel AS2 Client Endpoint | String
| *bridgeErrorHandler* (consumer) | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | boolean
| *sendEmptyMessageWhenIdle* (consumer) | If the polling consumer did not poll any files, you can enable this option to send an empty message (no body) instead. | false | boolean
| *exceptionHandler* (consumer) | To let the consumer use a custom ExceptionHandler. Notice if the option bridgeErrorHandler is enabled then this option is not in use. By default the consumer will deal with exceptions, that will be logged at WARN or ERROR level and ignored. |  | ExceptionHandler
| *exchangePattern* (consumer) | Sets the exchange pattern when the consumer creates an exchange. |  | ExchangePattern
| *pollStrategy* (consumer) | A pluggable org.apache.camel.PollingConsumerPollingStrategy allowing you to provide your custom implementation to control error handling usually occurred during the poll operation before an Exchange have been created and being routed in Camel. |  | PollingConsumerPollStrategy
| *lazyStartProducer* (producer) | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. | false | boolean
| *basicPropertyBinding* (advanced) | Whether the endpoint should use basic property binding (Camel 2.x) or the newer property binding with additional capabilities | false | boolean
| *synchronous* (advanced) | Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). | false | boolean
| *backoffErrorThreshold* (scheduler) | The number of subsequent error polls (failed due some error) that should happen before the backoffMultipler should kick-in. |  | int
| *backoffIdleThreshold* (scheduler) | The number of subsequent idle polls that should happen before the backoffMultipler should kick-in. |  | int
| *backoffMultiplier* (scheduler) | To let the scheduled polling consumer backoff if there has been a number of subsequent idles/errors in a row. The multiplier is then the number of polls that will be skipped before the next actual attempt is happening again. When this option is in use then backoffIdleThreshold and/or backoffErrorThreshold must also be configured. |  | int
| *delay* (scheduler) | Milliseconds before the next poll. You can also specify time values using units, such as 60s (60 seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour). | 500 | long
| *greedy* (scheduler) | If greedy is enabled, then the ScheduledPollConsumer will run immediately again, if the previous run polled 1 or more messages. | false | boolean
| *initialDelay* (scheduler) | Milliseconds before the first poll starts. You can also specify time values using units, such as 60s (60 seconds), 5m30s (5 minutes and 30 seconds), and 1h (1 hour). | 1000 | long
| *repeatCount* (scheduler) | Specifies a maximum limit of number of fires. So if you set it to 1, the scheduler will only fire once. If you set it to 5, it will only fire five times. A value of zero or negative means fire forever. | 0 | long
| *runLoggingLevel* (scheduler) | The consumer logs a start/complete log line when it polls. This option allows you to configure the logging level for that. | TRACE | LoggingLevel
| *scheduledExecutorService* (scheduler) | Allows for configuring a custom/shared thread pool to use for the consumer. By default each consumer has its own single threaded thread pool. |  | ScheduledExecutorService
| *scheduler* (scheduler) | To use a cron scheduler from either camel-spring or camel-quartz component | none | String
| *schedulerProperties* (scheduler) | To configure additional properties when using a custom scheduler or any of the Quartz, Spring based scheduler. |  | Map
| *startScheduler* (scheduler) | Whether the scheduler should be auto started. | true | boolean
| *timeUnit* (scheduler) | Time unit for initialDelay and delay options. | MILLISECONDS | TimeUnit
| *useFixedDelay* (scheduler) | Controls if fixed delay or fixed rate is used. See ScheduledExecutorService in JDK for details. | true | boolean
|===
// endpoint options: END
// spring-boot-auto-configure options: START
== Spring Boot Auto-Configuration

When using Spring Boot make sure to use the following Maven dependency to have support for auto configuration:

[source,xml]
----
<dependency>
  <groupId>org.apache.camel.springboot</groupId>
  <artifactId>camel-as2-starter</artifactId>
  <version>x.x.x</version>
  <!-- use the same version as your Camel core version -->
</dependency>
----

The component supports 32 options, which are listed below.

[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
| *camel.component.as2.basic-property-binding* | Whether the component should use basic property binding (Camel 2.x) or the newer property binding with additional capabilities | false | Boolean
| *camel.component.as2.bridge-error-handler* | Allows for bridging the consumer to the Camel routing Error Handler, which mean any exceptions occurred while the consumer is trying to pickup incoming messages, or the likes, will now be processed as a message and handled by the routing Error Handler. By default the consumer will use the org.apache.camel.spi.ExceptionHandler to deal with exceptions, that will be logged at WARN or ERROR level and ignored. | false | Boolean
| *camel.component.as2.configuration.api-name* | What kind of operation to perform |  | AS2ApiName
| *camel.component.as2.configuration.as2-from* | The value of the AS2From header of AS2 message. |  | String
| *camel.component.as2.configuration.as2-message-structure* | The structure of AS2 Message. One of: PLAIN - No encryption, no signature, SIGNED - No encryption, signature, ENCRYPTED - Encryption, no signature, ENCRYPTED_SIGNED - Encryption, signature |  | AS2MessageStructure
| *camel.component.as2.configuration.as2-to* | The value of the AS2To header of AS2 message. |  | String
| *camel.component.as2.configuration.as2-version* | The version of the AS2 protocol. | 1.1 | String
| *camel.component.as2.configuration.client-fqdn* | The Client Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *camel.component.as2.configuration.compression-algorithm* | The algorithm used to compress EDI message. |  | AS2CompressionAlgorithm
| *camel.component.as2.configuration.decrypting-private-key* | The key used to encrypt the EDI message. |  | PrivateKey
| *camel.component.as2.configuration.disposition-notification-to* | The value of the Disposition-Notification-To header. Assigning a value to this parameter requests a message disposition notification (MDN) for the AS2 message. |  | String
| *camel.component.as2.configuration.edi-message-transfer-encoding* | The transfer encoding of EDI message. |  | String
| *camel.component.as2.configuration.edi-message-type* | The content type of EDI message. One of application/edifact, application/edi-x12, application/edi-consent |  | ContentType
| *camel.component.as2.configuration.encrypting-algorithm* | The algorithm used to encrypt EDI message. |  | AS2EncryptionAlgorithm
| *camel.component.as2.configuration.encrypting-certificate-chain* | The chain of certificates used to encrypt EDI message. |  | Certificate[]
| *camel.component.as2.configuration.from* | The value of the From header of AS2 message. |  | String
| *camel.component.as2.configuration.mdn-message-template* | The template used to format MDN message |  | String
| *camel.component.as2.configuration.method-name* | What sub operation to use for the selected operation |  | String
| *camel.component.as2.configuration.request-uri* | The request URI of EDI message. | / | String
| *camel.component.as2.configuration.server* | The value included in the Server message header identifying the AS2 Server. | Camel AS2 Server Endpoint | String
| *camel.component.as2.configuration.server-fqdn* | The Server Fully Qualified Domain Name (FQDN). Used in message ids sent by endpoint. | camel.apache.org | String
| *camel.component.as2.configuration.server-port-number* | The port number of server. |  | Integer
| *camel.component.as2.configuration.signed-receipt-mic-algorithms* | The list of algorithms, in order of preference, requested to generate a message integrity check (MIC) returned in message dispostion notification (MDN) |  | String[]
| *camel.component.as2.configuration.signing-algorithm* | The algorithm used to sign EDI message. |  | AS2SignatureAlgorithm
| *camel.component.as2.configuration.signing-certificate-chain* | The chain of certificates used to sign EDI message. |  | Certificate[]
| *camel.component.as2.configuration.signing-private-key* | The key used to sign the EDI message. |  | PrivateKey
| *camel.component.as2.configuration.subject* | The value of Subject header of AS2 message. |  | String
| *camel.component.as2.configuration.target-hostname* | The host name (IP or DNS name) of target host. |  | String
| *camel.component.as2.configuration.target-port-number* | The port number of target host. -1 indicates the scheme default port. |  | Integer
| *camel.component.as2.configuration.user-agent* | The value included in the User-Agent message header identifying the AS2 user agent. | Camel AS2 Client Endpoint | String
| *camel.component.as2.enabled* | Whether to enable auto configuration of the as2 component. This is enabled by default. |  | Boolean
| *camel.component.as2.lazy-start-producer* | Whether the producer should be started lazy (on the first message). By starting lazy you can use this to allow CamelContext and routes to startup in situations where a producer may otherwise fail during starting and cause the route to fail being started. By deferring this startup to be lazy then the startup failure can be handled during routing messages via Camel's routing error handlers. Beware that when the first message is processed then creating and starting the producer may take a little time and prolong the total processing time of the processing. | false | Boolean
|===
// spring-boot-auto-configure options: END

== Client Endpoints:

Client endpoints use the endpoint prefix *`client`* followed by the name of a method
and associated options described next. The endpoint URI MUST contain the prefix *`client`*.

[source]
----
as2://client/method?[options]
----

Endpoint options that are not mandatory are denoted by *[]*. When there
are no mandatory options for an endpoint, one of the set of *[]* options
MUST be provided. Producer endpoints can also use a special
option *`inBody`* that in turn should contain the name of the endpoint
option whose value will be contained in the Camel Exchange In message.

Any of the endpoint options can be provided in either the endpoint URI,
or dynamically in a message header. The message header name must be of
the format *`CamelAS2.<option>`*. Note that the *`inBody`* option
overrides message header, i.e. the endpoint
option *`inBody=option`* would override a *`CamelAS2.option`* header.

If a value is not provided for the option *defaultRequest* either in the
endpoint URI or in a message header, it will be assumed to be `null`.
Note that the `null` value will only be used if other options do not
satisfy matching endpoints.

In case of AS2 API errors the endpoint will throw a
RuntimeCamelException with a
*org.apache.http.HttpException* derived exception
cause.

[width="100%",cols="10%,10%,70%",options="header"]
|===
|Method |Options |Result Body Type

|send |ediMessage, requestUri, subject, from, as2From, as2To, as2MessageStructure, ediMessageContentType, ediMessageTransferEncoding, dispositionNotificationTo, signedReceiptMicAlgorithms |org.apache.http.protocol.HttpCoreContext
|===

URI Options for _client_

[width="100%",cols="10%,90%",options="header"]
|===
|Name |Type

|ediMessage |String

|requestUri |String

|subject |String

|from |String

|as2From |String

|as2To |String

|as2MessageStructure |org.apache.camel.component.as2.api.AS2MessageStructure

|ediMessageContentType |String

|ediMessageTransferEncoding |String

|dispositionNotificationTo |String

|signedReceiptMicAlgorithms |String[]
|===

== Server Endpoints:

Server endpoints use the endpoint prefix *`server`* followed by the name of a method
and associated options described next. The endpoint URI MUST contain the prefix *`server`*.

[source]
----
as2://server/method?[options]
----

Endpoint options that are not mandatory are denoted by *[]*. When there
are no mandatory options for an endpoint, one of the set of *[]* options
MUST be provided. Producer endpoints can also use a special
option *`inBody`* that in turn should contain the name of the endpoint
option whose value will be contained in the Camel Exchange In message.

Any of the endpoint options can be provided in either the endpoint URI,
or dynamically in a message header. The message header name must be of
the format *`CamelAS2.<option>`*. Note that the *`inBody`* option
overrides message header, i.e. the endpoint
option *`inBody=option`* would override a *`CamelAS2.option`* header.

If a value is not provided for the option *defaultRequest* either in the
endpoint URI or in a message header, it will be assumed to be `null`.
Note that the `null` value will only be used if other options do not
satisfy matching endpoints.

In case of AS2 API errors the endpoint will throw a
RuntimeCamelException with a
*org.apache.http.HttpException* derived exception
cause.

[width="100%",cols="10%,10%,70%",options="header"]
|===
|Method |Options |Result Body Type

|listen |requestUriPattern |org.apache.http.protocol.HttpCoreContext
|===

URI Options for _server_

[width="100%",cols="10%,90%",options="header"]
|===
|Name |Type

|requestUriPattern |String
|===