allthingssecurity opened a new pull request, #27855:
URL: https://github.com/apache/camel/pull/27855

   # Description
   
   [CAMEL-25658](https://issues.apache.org/jira/browse/CAMEL-25658)
   
   Follow-up of the review of #27802 
([CAMEL-25615](https://issues.apache.org/jira/browse/CAMEL-25615), merged), 
which named "a client per exchange that is never closed" as worth its own JIRA.
   
   On main:
   - `BonitaStartProducer.process` called `BonitaAPIBuilder.build(config)` for 
every exchange, and every call built a new JAX-RS `Client` that nothing closed.
   - `BonitaAuthFilter` logs in before every request, each time with a new 
`Client` that it did not close either.
   
   So every exchange without a file input (process lookup and case creation, 
each after a login) left three clients open, and every exchange with a file 
input four (the upload is one more request after one more login).
   
   Changes:
   - The producer creates one client in `doStart`, builds its `BonitaAPI` on it 
and uses it for all its exchanges; `doStop` closes the client. A stopped and 
started producer creates a new one.
   - New `BonitaAPIBuilder.build(BonitaAPIConfig, Client)`: builds the API on a 
client that the caller owns and closes (it registers the JSON provider and the 
login filter on it, and binds the upload helper to it with 
`BonitaAPIUtil.forClient`, as `build(BonitaAPIConfig)` does since #27802). 
`build(BonitaAPIConfig)` keeps its behaviour for other callers (a new client, 
not closed) and now says so in its javadoc.
   - `BonitaAuthFilter` closes the client of a login after it has read the 
cookies of the answer.
   
   What changes for users: the endpoint options hostname, port, username and 
password are read when the producer starts, no longer for every exchange (the 
process name is still read per exchange). I did not add an upgrade-guide note 
for this; please say if one is wanted.
   
   Not changed: the login before every request (the filter still logs in for 
each request, as on main), and the deprecated `BonitaAPIUtil.getInstance` and 
2-argument `BonitaAPI` constructor from #27802 (not used by Camel; each still 
creates a client of its own).
   
   Relation to #27802: it is merged, and this branch is rebased on it. Since 
#27802 the upload helper uses the client of the `BonitaAPI`, so with this 
change a file input is uploaded with the client of the producer, and each 
endpoint still uploads to its own server (the four tests of 
`BonitaStartCaseFileUploadTest` from #27802 pass, two of them send through two 
endpoints to two servers).
   
   Tests:
   - New `BonitaStartProducerClientTest` (3 tests): a route to a WireMock 
Bonita server; the clients are seen through a static Mockito mock of 
`ClientBuilder.newBuilder()` that records what the real builder builds. Every 
client built is counted.
     - `oneClientForAllTheExchangesOfTheProducerClosedOnStop`: three exchanges, 
then one client open; after the context stops, none.
     - `fileInputIsUploadedWithTheClientOfTheProducer`: three exchanges with a 
file input (three uploads), then one client open; after the context stops, none.
     - `routeStartedAgainGetsAClientOfItsOwn`: one exchange, the route stops 
(no client open), the route starts again and two more exchanges go through with 
one client open.
   - Without the change (current main) all three fail: `clients still open 
after three exchanges, of 9 created ==> expected: <1> but was: <9>`, `clients 
still open after three exchanges with a file input, of 12 created ==> expected: 
<1> but was: <12>` and `clients still open after the route stopped, of 3 
created ==> expected: <0> but was: <3>`.
   - camel-bonita with the change: 25 tests, 0 failures, with test reruns 
switched off.
   
   What was not run: nothing against a Bonita server (the manual integration 
test of the module needs one). What a CXF client keeps until it is garbage 
collected was not measured, so I do not claim more than "not closed".
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [x] If this is a large change, bug fix, or code improvement, I checked 
there is a [JIRA issue](https://issues.apache.org/jira/browse/CAMEL) filed for 
the change (usually before you start working on it).
     [CAMEL-25658](https://issues.apache.org/jira/browse/CAMEL-25658)
   
   # Apache Camel coding standards and style
   
   - [x] I checked that each commit in the pull request has a meaningful 
subject line and body.
   - [ ] I have run `mvn clean install -DskipTests` locally from root folder 
and I have committed all auto-generated changes.
     (I built and tested camel-bonita, including the formatter and import-sort 
plugins. I did not run the full root build.)
   
   # AI-assisted contributions
   
   - [x] If this PR includes AI-generated code, commits have proper 
co-authorship attribution (e.g., `Co-authored-by` trailers) and the PR 
description identifies the AI tool used.
     This PR was prepared with Claude Code (Claude Opus 5.5). The commit 
carries a `Co-Authored-By` trailer.
   
   _Claude Code on behalf of allthingssecurity_
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


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

Reply via email to