[
https://issues.apache.org/jira/browse/TIKA-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18045912#comment-18045912
]
Nicholas DiPiazza commented on TIKA-4579:
-----------------------------------------
I've created a pull request to address this issue:
https://github.com/apache/tika/pull/2465
Changes include:
* Modified AbstractComponentManager.saveComponent() to support updates instead
of throwing exception on duplicate IDs
* Removed reflection hack from TikaGrpcServerImpl.saveFetcher()
* Updated JavaDocs for FetcherManager, EmitterManager, and
AbstractComponentManager
* Updated FetcherManagerTest to verify update behavior
* All existing tests pass
This enables tika-grpc to properly update fetcher/emitter configurations at
runtime without using reflection hacks.
> Add the ability to save pipes configs
> -------------------------------------
>
> Key: TIKA-4579
> URL: https://issues.apache.org/jira/browse/TIKA-4579
> Project: Tika
> Issue Type: Sub-task
> Reporter: Nicholas DiPiazza
> Priority: Major
>
> The fetcher and emitter managers need the ability to save/update
> configurations at runtime.
> h2. Background
> The TikaGrpcServer currently uses reflection hacks to update fetcher
> configurations because the FetcherManager.saveFetcher() method threw an
> exception when trying to save a fetcher with an ID that already exists.
> h2. Use Case
> A practical scenario for this functionality:
> # tika-grpc server starts with no fetcher configs in the tika-config (blank
> slate)
> # Users call the saveFetcher gRPC method to create new fetcher configurations
> # Users can then use those fetchers
> # Users may need to update/modify existing fetcher configurations
> h2. Solution Implemented
> Modified the AbstractComponentManager.saveComponent() method to support both
> creating new and updating existing component configurations.
> h3. Changes Made:
> *AbstractComponentManager.saveComponent()* - Changed behavior from throwing
> exception on duplicate IDs to supporting updates:
> * Removed the duplicate ID check that threw TikaConfigException
> * When updating an existing component, the cached instance is cleared to
> force re-instantiation
> * Added logging to distinguish between creating new configs vs updating
> existing ones
> *TikaGrpcServerImpl.saveFetcher()* - Removed reflection hack:
> * Deleted the reflection-based code that was forcibly clearing the cache
> * Now simply calls fetcherManager.saveFetcher() which handles updates properly
> *Updated JavaDocs* - Modified documentation for:
> * AbstractComponentManager.saveComponent()
> * FetcherManager.saveFetcher()
> * EmitterManager.saveEmitter()
> * Changed from "adds a component" to "adds or updates a component"
> * Removed mentions of exceptions for duplicate IDs
> *Updated Tests* - Modified FetcherManagerTest:
> * Changed test from expecting TikaConfigException to verifying update behavior
> * Verifies that updating a fetcher clears the cache and creates a new instance
> * Ensures the config store contains only one fetcher after update
> h2. Security Note
> This "save" functionality stores configurations in-memory only. Since
> tika-grpc is secured via mutual TLS, only authorized users can modify
> configurations at runtime.
> h2. Technical Details
> * Component configurations are stored in a Map (configStore)
> * Component instances are cached in a separate Map (componentCache)
> * When updating an existing config, only the cache is cleared, not the config
> store entry
> * The new configuration will be instantiated lazily on next use via
> getComponent()
> * Runtime modifications require allowRuntimeModifications=true when loading
> the manager
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
