Adaptation to the context

...

• _portal

• _portal@config

• _portal@config@picker

The path _portal@$config@picker designates a configuration defined in 3 folders whose relative paths are successively :

...

You can implement your own header-dependent post processor by implementing the fr.wedia.confres.core.model.processor.AbstractHeaderPostProcessor abstraction and its String getValue(String,Collection<fr.wedia.confres.api.util.Headers>) method. See others methods getValueFoNoHeaders and getValueForNull to return a value respectively for no headers or null headers. See the javadoc for more information

Parameter processor

Abstraction

fr.wedia.confres.core.model.processor.AbstractParameterPostProcessor is a base for processors whose value depends on parameters.

Customizings postprocessors

...

• json, string or file, (at least one is mandatory), that contains JSon (or XJSon), multiple values allowed (JSon lenient parsing is not supported)

• xjson, boolean, optional (default is false). If true, if the jsons passed in parameter must be considered as xjson, false, otherwise (not to be confused with the xjson option which controls how the response json is formed)

• lenient, boolean, optional (default is false). If true, the xjsons passed in parameter must be processed as lenient

• explain, boolean optional (default is false). If true, the result is an explain, if false, the result is a merge. (works only with end point /test)

• locations, optional
  This parameter allows to give location names to each JSon. Indeed, as there is no corresponding physical location (no files or folders), a virtual location is generated with just an incremental index (from 1 to n, and Root for root). This parameter allows to name the layers.

  • either by a JSon array (example: locations=[_base,_base@test])

  • or by strings (example ...&locations=_base&locations=_base%40test&...)

• pathFilter (see get configuration and explain configuration)

• pathFilterMode (see get configuration and explain configuration)

• nodesWithPaths (see get configuration and explain configuration)

• options (see get configuration and explain configuration)

• verbosity, only if explain (see get configuration and explain configuration)

processors list

Gets processors list (variable names)

...

Put an exclusive access lock (if not already owned).

Response

unlock

DELETE /fs/lock(operation ID: lockDelete)

Delete the owned lock.

Response

get lock

GET /fs/lock(operation ID: lockGet)

Test if lock is owned (and extend it)

Auto locking

Any service that creates, modifies or deletes configuration files automatically creates a lock (enableable/disableable by plugin configuration).

...

This service allows to modify (patch or replace) the configuration in a layer, or in a subfolder of a layer

Parameters

• layer, (see Basic file operatirons/Parameters for details), mandatory
  denotes the configuration layer

• path, (see Basic file operatirons/Parameters for details), optional, can be single or multiple, depending on the presence of content
  specifies the relative xjsonpath (to the configuration layer) where to write

• content, string or file(multipart/formdata), optional
  The XJSON (lenient) to write. If this parameter is not specified, multiple paths can be specified. If this parameter is specified, only one path or none can be specified (in this case, we write directly to the layer)

• wip, boolean, optional(default is false)⛔
  True to write to wip data

• delete, boolean, optional(default is false)⛔
  True to write delete overrides. In this mode, the primitive values in the xjson (if present) are ignored.

• options, JSON with the following properties

  • merge, boolean, optional (true by default)
    True to keep the other properties already existing in the namespace we are writing. If false, All other properties in the written namespace will be removed
    

    For example, the name space is currently

    Code Block
    /a /b /c c1.json = "c1" c2.json = "c2" /d d1.json = "d1"

    We write this XJSON:

    Code Block
    language json
    { "a": "b": { "c": { "c2": "c2>modified", "c3": "new" } } } }

    With merge=true, the result is

    Code Block
    /a /b /c c1.json = "c1" c2.json = "c2>modified" c3.json = "new" /d d1.json = d1

    With merge=false, the result is

    Code Block
    /a /b /c c2.json = "c2>modified" c3.json = "new"

  • mkLayers, boolean, optional(false by default)
    True to create layer if it doesn’t exists

  • keepFormat, boolean, optional(false by default)
    By default, only JSon is written to files (or empty content for .delete files). If keepFormat is true, and the JSon value is string, and the target file is already existing, the original format (from the suffix) is kept.
    Example
    Here the current file system:

    Code Block
    language json
    /a /b /c c1.json = "c1" c2.txt= c2 /d d1.json = "d1"

    XJSON to write:

    Code Block
    language json
    { "a": "b": { "c": { "c1": "c1>modified", "c2": "c2>modified" } } } }

    Result with keepFormat=false

    Code Block
    language json
    /a /b /c c1.json = "c1>modified" c2.json = "c2>modified" /d d1.json = "d1"

    Result with keepFormat=true

    Code Block
    /a /b /c c1.json = "c1>modified" c2.txt= c2>modified /d d1.json = "d1"

  • keepDelete, boolean (optional, true by default)
    when a property is written, the files concerning this same property are deleted (the writing constitutes a replacement). This option indicates how the file with the delete extension is to be considered during this replacement: by default, it is not deleted (keepDelete=true). You can force the deletion by setting keepDelete to false.

  • keepProperty, boolean (optional, true by default)
    when you write .delete files in path mode, the files concerning the same property aren’t deleted. You can force deletion by setting keepProperty to false.

...

Command name: fs/config/delete

• layer, (see Basic file operatirons/Parameters for details), mandatory
  denotes the configuration layer

• path, (see Basic file operatirons/Parameters for details), optional, can be single or multiple, depending on the presence of content
  specifies the relative xjsonpath (to the configuration layer) where to write

• content, string or file(multipart/formdata), optional
  The XJSON to write. If this parameter is not specified, multiple paths can be specified. If this parameter is specified, only one path or none can be specified (in this case, we write directly to the layer).
  This XJSON is not lenient. Arrays are used to specify the operation (see details in the paragraph Delete configuration (write delete files and/or remove files) with a XJSON):

  • DELETE

  • REMOVE

• wip, boolean, optional(default is false)⛔
  True to write to wip data

• options, JSON with the following properties

  • deleteNotEmpty, boolean (optional, true by default)
    if false, REMOVE option is not applyed on not empty directories

  • mkLayers, boolean (optional, false by default)

...

Some errors are not raised in error if there are several layer names. In this case, see the state property in the response.

Example

curl --request POST \
  --url 'http://<host>/api/portalconfig/fs/layer?layer=_portal%40testcreate&layer=_portal%40testcreate1&layer=_portal%40testcreate2'

...

test doc

...

test 1

...

test 2

...

test 3

...

item 1
text

• sub item 1

• sub item 2
  

...