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]