[
https://issues.apache.org/jira/browse/TIKA-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115692#comment-18115692
]
ASF GitHub Bot commented on TIKA-4881:
--------------------------------------
Copilot commented on code in PR #3178:
URL: https://github.com/apache/tika/pull/3178#discussion_r4018339895
##########
tika-server/tika-server-core/src/main/java/org/apache/tika/server/core/resource/UnpackerResource.java:
##########
@@ -224,15 +233,28 @@ public Response unpackAll(InputStream is, @Context
HttpHeaders httpHeaders, @Con
* @param info URI info
* @return streaming zip response
*/
- @jakarta.ws.rs.Path("/all{id:(/.*)?}")
+ @jakarta.ws.rs.Path("/all")
+ @POST
+ @Consumes("multipart/form-data")
+ @Produces("application/zip")
+ public Response unpackAllWithConfig(List<Attachment> attachments,
+ @Context HttpHeaders httpHeaders)
throws Exception {
+ return unpackAllWithConfig(attachments, httpHeaders, null);
+ }
+
+ /** As {@code POST /unpack/all}, with the sidecar handler named in the
path. */
+ @jakarta.ws.rs.Path("/all/{" + HANDLER_TYPE_PARAM + "}")
@POST
@Consumes("multipart/form-data")
@Produces("application/zip")
- public Response unpackAllWithConfig(List<Attachment> attachments, @Context
HttpHeaders httpHeaders, @Context UriInfo info) throws Exception {
- rejectPresetInWildcard(info);
+ public Response unpackAllWithConfig(List<Attachment> attachments, @Context
HttpHeaders httpHeaders,
+
@jakarta.ws.rs.PathParam(HANDLER_TYPE_PARAM) String handlerTypeName)
Review Comment:
This route change also removes the existing `POST /unpack/all/config`
endpoint: the old `/all{id:(/.*)?}` method accepted that path as the multipart
config variant, while the new `/all/{handler}` treats `config` as a handler
name and `applyHandler` returns 400. `release-tools/uat/run-uat.sh` and the
integration-test documentation still exercise this URL, so either preserve an
explicit compatibility route or update all shipped UAT/docs and call out the
breaking API change.
##########
tika-server/tika-server-core/src/main/java/org/apache/tika/server/core/resource/UnpackerResource.java:
##########
@@ -100,7 +99,7 @@
* "unpack-config": {
* "outputFormat": "FRICTIONLESS",
* "outputMode": "ZIPPED",
- * "includeFullMetadata": true
+ * "includeMetadata": true
* }
Review Comment:
The example now uses the new `includeMetadata` setting, but the output tree
below still says `metadata.json` is conditional on the deprecated
`includeFullMetadata=true`. With this change Frictionless writes it by default
unless `includeMetadata=false`; update that description so the class-level API
documentation matches the new behavior.
##########
docs/modules/ROOT/pages/pipes/unpack-config.adoc:
##########
@@ -247,13 +252,120 @@ When using Frictionless output format, the ZIP archive
contains:
----
output.zip
├── datapackage.json # Manifest with file list, SHA256 hashes, mimetypes
-├── metadata.json # Full RMETA metadata (if includeFullMetadata=true)
+├── metadata.json # Full RMETA metadata (unless includeMetadata=false)
└── unpacked/
├── 00000001.pdf
├── 00000002.png
└── ...
----
+The `tk:content` field inside `metadata.json` (and inside the per-file
`.metadata.json`
+sidecars `includeMetadata` adds to REGULAR zip output) is Markdown by default.
On tika-server
+change it with `/unpack/all/{handlerType}` or a `content-handler-factory` in
the `config`
+part; in a config, the factory alone. Each entry records the handler it was
written with in
+`tk:content-handler-type`:
+
+[source,json]
+----
+{
+ "unpack-config": { "outputFormat": "FRICTIONLESS" },
+ "basic-content-handler-factory": { "type": "XML" }
+}
+----
+
+To get metadata with no extracted text at all
> Make /unpack and /rmeta symmetrical with /tika in content handler paths
> -----------------------------------------------------------------------
>
> Key: TIKA-4881
> URL: https://issues.apache.org/jira/browse/TIKA-4881
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> Over on Solr when trying to upgrade to 4.0.0, they found that
> /rmeta/config/xml doesn't work, but /tika/config/xml works.
>
> We shouldn't have this lack of symmetry.
>
> Arguably, we shouldn't have /tika/config/xml at all because if you're
> submitting a config, you can set the handler in the config.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
