etzel-mes opened a new pull request, #28387:
URL: https://github.com/apache/camel/pull/28387

   # Description
   
   Upgrades `camel-plc4x` from PLC4X 0.13.1 to 1.0.0 (JIRA: CAMEL-25617). PLC4X 
1.0.0 requires Java 21, which Camel main has since CAMEL-22996, and it removed 
the `plc4j-scraper` module the triggered consumer was built on.
   
   The user-facing contract is unchanged: the same endpoint options (`trigger`, 
`period`, `tags`, `autoReconnect`), the same `Map<String,Object>` body, the 
same one-shot consumer, polling consumer and producer. Nothing was added to or 
removed from the generated endpoint metadata.
   
   **Triggered consumer.** With the scraper gone, the consumer with `trigger` 
is now a Camel `ScheduledPollConsumer` on the endpoint's single connection:
   
   ```text
   every `period` ms (fixed delay, first poll at route start)
     reconnectIfNeeded()
     read trigger tag + data tags in ONE request
     if any tag not OK or the read failed
       remembered trigger := unknown; report through the exception handler
     else if trigger is true and remembered trigger was not true
       deliver the data tags as Map<String,Object> (trigger tag excluded)
     remembered trigger := trigger
   ```
   
   This keeps the scraper's semantics (rising edge only, a trigger already true 
on the first read emits once, a held trigger never re-emits) and changes what 
was broken or implicit: the data tags come from the same read as the edge (the 
scraper read them in a later separate request on another connection), a failed 
read no longer stops triggering for the life of the route (the scraper's 
collector died on the first failure), stop cancels the schedule, and no scraper 
thread pools remain (each scraper start leaked up to 20 non-daemon threads). 
The 0.13.1 behaviour was locked by route tests first (commit 1) and the port is 
proven by the same tests passing (commits 2 and 5); the two Mockito tests that 
captured the scraper's constructors, including the stop test from CAMEL-25292, 
are re-expressed at the route seam.
   
   PLC4X 1.0.0 offers `plc4j-tools-event-pump` in place of the scraper; it is 
not used here because its cached read request stays bound to the connection 
that built it, so it never recovers from a PLC restart (apache/plc4x#2832, 
found while preparing this change). Camel's own polling consumer gives the 
scheduling, overlap guarantee, stop and error routing without a new dependency.
   
   **Other changes.** `reconnectIfNeeded()` now closes a lost connection and 
takes a new one from the driver manager instead of calling `connect()` on it; 
the 1.0.0 S7 and EtherNet/IP connections refuse to connect again once their 
transport closed, so without this neither the producer nor the consumers 
recovered after a PLC restart. The endpoint no longer passes its own Camel 
options (`trigger`, `period`, `tag.*`, `autoReconnect`, generic consumer 
options) to the driver inside the connection string; 1.0.0 drivers log a 
warning per unknown parameter. `Constants.PLC_NAME` (scraper-only) is removed. 
The upgrade guide gets a camel-plc4x section with the PLC4X-side changes (Java 
21, renamed connection parameters, OPC UA secure defaults, with a link to the 
PLC4X release notes) and the behaviour changes above.
   
   **Not changed, for the record.** With the default `autoReconnect=false` the 
endpoint stops itself on the first lost connection while the route keeps 
polling; that is pre-existing and shared with the producer. 
`plc4j-tools-event-pump` still arrives transitively through 
`plc4j-utils-subscription-emulation` (ab-eth, eip, firmata) with the module's 
long-standing jackson/woodstox exclusions applying under it; the EtherNet/IP 
path was run with it.
   
   **Verification.** Module build only (`mvn install` in 
`components/camel-plc4x`; the root build was not run). Module suite: 35 tests, 
green in three consecutive runs with `-Dsurefire.rerunFailingTestsCount=0`; 
`-Psourcecheck` clean; the catalog copy of the component doc is byte-identical. 
Live, against protocol simulators with writable memory (S7: snap7 1.4.2 server; 
Modbus TCP: `oitc/modbus-server`; EtherNet/IP: libplctag 2.7.2 `ab_server` as 
ControlLogix), a producer route wrote the trigger bit and the data tags while a 
triggered consumer polled at `period=100`: on all three, a false→true edge 
delivers exactly one exchange whose body holds the values written just before 
the edge, a trigger held for 2.5 s delivers no second exchange, 20 edges at 1 
Hz delivered 20 matching bodies, poll spacing was 105–109 ms mean (max 132 ms), 
the JVM used about 2 % CPU, a 10 s simulator stop logged one warning per poll 
and the consumer recovered 0.1–0.6 s after the simulator came back; the u
 nknown-parameter warnings are gone. Not verified against real PLCs.
   
   **Backport.** Not backportable to 4.22.x: PLC4X 1.0.0 requires Java 21.
   
   @davsclaus @oscerd could you have a look? (I cannot request reviewers.) JIRA 
user: mardonius.
   
   # 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).
   
   # 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.
   
   # 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.
   
   The code, tests and documentation were written with Claude Code (Claude 
Fable 5.1) under my direction; every commit carries the `Co-Authored-By` 
trailer.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   
   _Claude Code on behalf of etzel-mes_
   


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