SamaSVM commented on PR #6379: URL: https://github.com/apache/fineract/pull/6379#issuecomment-6288559708
@galovics Thank you for reviewing this PR. Regarding all four points: **1. `ContentProcessorTest` — restored** Kept the diff to a minimum: only the `SizeContentProcessor` / `SIZE_RESULT_VALUE` usage was removed (since that class is deleted in this PR), along with the size-related parts of the corresponding `log.info(...)` calls. `process()` and `base64()` are otherwise left unchanged, even though they now exercise the identical `base64DecoderContentProcessor.process(DATA_BASE64)` path without `sizeContentProcessor`. I haven't changed the test structure beyond what was required to remove the deleted class. **2. `ContentDetectorContext`, manager indirection, `ContentPipe`, and `getDefaultBufferSize()` — verified** - **`ContentPipe` and `FineractProperties.getContent().getDefaultBufferSize()`** are still used by all four remaining processors (`Base64Encoder`, `Base64Decoder`, `DataUrlEncoder`, and `DataUrlDecoder`). They are also used outside this module by `BulkImportWorkbookServiceImpl` and `BulkImportEventListener` in `fineract-provider`. The `default-buffer-size` property is wired in `application.properties`. The Gzip processors were not their last consumers. - **`ContentDetectorContext`** is part of the `ContentDetector` API itself, serving as its parameter/result type. It is used by `MimeContentPolicy`, `FileContentStoreService`, `DocumentApiResource`, `ImageReadPlatformServiceImpl`, and `ImageWritePlatformServiceImpl`. - **`DefaultContentDetectorManager`** is indeed a thin pass-through to the single remaining `TikaContentDetector` implementation, injected by its concrete type rather than as a `List<ContentDetector>`. Simplifying this indirection is a legitimate design improvement, but it would constitute an API change rather than dead-code removal. I've therefore kept it out of this PR's scope and will address it in a follow-up. **3. Bean names and parameter-key lookups — verified** There are no `getBean(...)` calls for any `ContentProcessor` or `ContentDetector` anywhere in the repository; all dependencies are injected by type. I also searched for the removed parameter keys and class names (`gzip` / `Gzip` / `GZIP`, `SizeContentProcessor`, `FileContentDetector`, `size.result`, and `ContentPathSanitizerException`). The only remaining Gzip-related references in the repository are an unrelated tar-compression flag in a CI workflow and `Compression.GZIP` in `fineract-war/build.gradle`. The parameter keys (e.g., `gzip.encode.buffer-size`) were never Spring properties. They were used exclusively as keys in `ContentProcessorContext`'s in-memory parameter map, so no downstream configuration could reference them as application properties. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
