[ 
https://issues.apache.org/jira/browse/TIKA-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046004#comment-18046004
 ] 

Hudson commented on TIKA-4579:
------------------------------

SUCCESS: Integrated in Jenkins build Tika ยป tika-main-jdk17 #1122 (See 
[https://ci-builds.apache.org/job/Tika/job/tika-main-jdk17/1122/])
TIKA-4579: Add ability to update fetcher/emitter configurations (#2465) 
(github: 
[https://github.com/apache/tika/commit/c4c3441cd2b5356f90ffa85e74ecd87655839944])
* (edit) 
tika-pipes/tika-pipes-integration-tests/src/test/java/org/apache/tika/pipes/core/fetcher/FetcherManagerTest.java
* (edit) 
tika-grpc/src/main/java/org/apache/tika/pipes/grpc/TikaGrpcServerImpl.java
* (edit) 
tika-pipes/tika-pipes-core/src/main/java/org/apache/tika/pipes/core/AbstractComponentManager.java
* (edit) 
tika-pipes/tika-pipes-core/src/main/java/org/apache/tika/pipes/core/fetcher/FetcherManager.java
* (edit) 
tika-pipes/tika-pipes-integration-tests/src/test/java/org/apache/tika/pipes/core/emitter/EmitterManagerTest.java
* (edit) 
tika-pipes/tika-pipes-core/src/main/java/org/apache/tika/pipes/core/emitter/EmitterManager.java


> 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)

Reply via email to