manifests.rst 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183
  1. .. _rest_api_manifests:
  2. Manifests
  3. =========
  4. GeoServer provides a REST service to expose a listing of all loaded JARs and resources on the running instance. This is useful for bug reports and to keep track of extensions deployed into the application. There are two endpoints for accessing this information:
  5. * ``about/manifest``—Retrieves details on all loaded JARs
  6. * ``about/version``—Retrieves details for the high-level components: GeoSever, GeoTools, and GeoWebCache
  7. * ``about/status``-Retrieves details for the status of all loaded and configured modules
  8. ``/about/manifest[.<format>]``
  9. ------------------------------
  10. This endpoint retrieves details on all loaded JARs.
  11. All the GeoServer manifest JARs are marked with the property ``GeoServerModule`` and classified by type, so you can use filtering capabilities to search for a set of manifests using regular expressions (see the :ref:`manifest <rest_api_manifests_manifest>` parameter) or a type category (see the :ref:`key <rest_api_manifests_key>` and :ref:`value <rest_api_manifests_value>` parameter).
  12. The available types are ``core``, ``extension``, or ``community``. To filter modules by a particular type, append a request with ``key=GeoServerModule&value=<type>``
  13. .. list-table::
  14. :header-rows: 1
  15. * - Method
  16. - Action
  17. - Status Code
  18. - Formats
  19. - Default Format
  20. - Parameters
  21. * - GET
  22. - List all manifests into the classpath
  23. - 200
  24. - HTML, XML, JSON
  25. - HTML
  26. - :ref:`manifest <rest_api_manifests_manifest>`, :ref:`key <rest_api_manifests_key>`, :ref:`value <rest_api_manifests_value>`
  27. * - POST
  28. -
  29. - 405
  30. -
  31. -
  32. -
  33. * - PUT
  34. -
  35. - 405
  36. -
  37. -
  38. -
  39. * - DELETE
  40. -
  41. - 405
  42. -
  43. -
  44. -
  45. Usage
  46. ~~~~~
  47. The model is very simple and is shared between the version and the resource requests to parse both requests.::
  48. <about>
  49. <resource name="{NAME}">
  50. <{KEY}>{VALUE}</{KEY}>
  51. ...
  52. </resource>
  53. ...
  54. </about>
  55. You can customize the results adding a properties file called :file:`manifest.properties` into the root of the data directory.
  56. Below is the default implementation that is used when no custom properties file is present::
  57. resourceNameRegex=.+/(.*).(jar|war)
  58. resourceAttributeExclusions=Import-Package,Export-Package,Class-Path,Require-Bundle
  59. versionAttributeInclusions=Project-Version:Version,Build-Timestamp,Git-Revision,
  60. Specification-Version:Version,Implementation-Version:Git-Revision
  61. where:
  62. * ``resourceNameRegex``—Group(1) will be used to match the attribute name of the resource.
  63. * ``resourceAttributeExclusions``—Comma-separated list of properties to exclude (deny-list), used to exclude parameters that are too verbose such that the resource properties list is left open. Users can add their JARs (with custom properties) having the complete list of properties.
  64. * ``versionAttributeInclusions``—Comma-separated list of properties to include (allow-list). Also supports renaming properties (using ``key:replace``) which is used to align the output of the ``versions`` request to the output of the web page. The model uses a map to store attributes, so the last attribute found in the manifest file will be used.
  65. .. _rest_api_manifests_manifest:
  66. ``manifest``
  67. ^^^^^^^^^^^^
  68. The ``manifest`` parameter is used to filter over resulting resource (manifest) names attribute using Java regular expressions.
  69. .. _rest_api_manifests_key:
  70. ``key``
  71. ^^^^^^^
  72. The ``key`` parameter is used to filter over resulting resource (manifest) properties name. It can be combined with the ``value`` parameter.
  73. .. _rest_api_manifests_value:
  74. ``value``
  75. ^^^^^^^^^
  76. The ``value`` parameter is used to filter over resulting resource (manifest) properties value. It can be combined with the ``key`` parameter.
  77. ``/about/version[.<format>]``
  78. -----------------------------
  79. This endpoint shows only the details for the high-level components: GeoServer, GeoTools, and GeoWebCache.
  80. .. list-table::
  81. :header-rows: 1
  82. * - Method
  83. - Action
  84. - Status Code
  85. - Formats
  86. - Default Format
  87. - Parameters
  88. * - GET
  89. - List GeoServer, GeoWebCache and GeoTools manifests
  90. - 200
  91. - HTML, XML, JSON
  92. - HTML
  93. - :ref:`manifest <rest_api_manifests_manifest>`, :ref:`key <rest_api_manifests_key>`, :ref:`value <rest_api_manifests_value>`
  94. * - POST
  95. -
  96. - 405
  97. -
  98. -
  99. -
  100. * - PUT
  101. -
  102. - 405
  103. -
  104. -
  105. -
  106. * - DELETE
  107. -
  108. - 405
  109. -
  110. -
  111. -
  112. ``/about/status[.<format>]``
  113. -----------------------------
  114. This endpoint shows the status details of all installed and configured modules.Status details always include human readable name, and module name. Optional details include version, availability, status message, and links to documentation.
  115. .. list-table::
  116. :header-rows: 1
  117. * - Method
  118. - Action
  119. - Status Code
  120. - Formats
  121. - Default Format
  122. - Parameters
  123. * - GET
  124. - List module statuses
  125. - 200
  126. - HTML, XML, JSON
  127. - HTML
  128. -
  129. * - POST
  130. -
  131. - 405
  132. -
  133. -
  134. -
  135. * - PUT
  136. -
  137. - 405
  138. -
  139. -
  140. -
  141. * - DELETE
  142. -
  143. - 405
  144. -
  145. -
  146. -