etzel-mes commented on PR #28387: URL: https://github.com/apache/camel/pull/28387#issuecomment-6382413374
Thanks @davsclaus, all points checked against the 0.13.1 and 1.0.0 jars. Pushed 98c1acda2c5, d5eef55cd6c and bd9fbb96aa3. Upgrade guide (bd9fbb96aa3): - Tag addresses: confirmed. The 1.0.0 driver patterns put the array selection before the data type, and the old form no longer parses. The guide now gives `holding-register:1:INT[4]` → `holding-register:1[0..3]:INT` and `%DB42:28.0:BYTE[4]` → `%DB42:28.0[0..3]:BYTE`, and notes that `[4]` before the type selects the single element at index 4 (`ArrayNotationParser` in plc4j-spi-drivers 1.0.0). It covers the `tag.*` options, `trigger` and the producer body. - `s7-light`: confirmed from the `PlcDriver` services file (0.13.1 lists `S7Driver` and `S7LightDriver`, 1.0.0 only `S7Driver`). The guide says `plc4x:s7-light://` no longer finds a driver and to use `plc4x:s7://`. - The failed-start note now says it also fails the CamelContext start, unless the route is supervised or has `autoStartup=false`. Non-blocking / suggestions: - Non-boolean trigger (d5eef55cd6c): a trigger value that is not a `Boolean` (a number, an array, or no value) now fails the poll with a `PlcException` naming the trigger address and the value type, so it reaches the consumer's exception handler and the remembered trigger is reset. New route test `aTriggerThatIsNotABooleanFailsThePoll`. - Timeout (d5eef55cd6c): the triggered read now waits at most 5 s, the same value as the producer, through one constant `Plc4XEndpoint.REQUEST_TIMEOUT_MILLIS`; on timeout the future is cancelled and the poll fails. - Connection replacement (98c1acda2c5): `connection` is `volatile`, and the replacement in `reconnectIfNeeded()`/`setupConnection()` and the close in `doStop()` run under the endpoint lock. I used a `synchronized (this)` block rather than synchronized methods so that the `autoReconnect=false` branch calls `stop()` after releasing the lock; otherwise a concurrent `stop()`, which holds the service lock and waits for the endpoint lock in `doStop()`, could deadlock with it. - The repeated WARN with `autoReconnect=false` I'd leave for a follow-up, as you suggested. Dependency tree, `components/camel-plc4x`, merge base dc990927b60 (PLC4X 0.13.1) vs this branch: | Artifact | before (0.13.1) | after (1.0.0) | |---|---|---| | plc4j-scraper | compile (direct) | absent | | plc4j-tools-event-pump | absent | runtime (driver → plc4j-utils-subscription-emulation) | | jackson-core, jackson-annotations, jackson-dataformat-yaml | compile (via scraper) | runtime (via event-pump) | | jackson-databind | compile (via scraper) | absent (exclusion holds) | | jackson-dataformat-xml | absent | runtime (via event-pump) | | woodstox-core | absent | absent (exclusion holds) | So the exclusions still hold and no Jackson artifact is in compile scope any more. The module no longer declares event-pump; it comes in at runtime through the drivers' subscription emulation, which only uses `EventPump`, `TagBatch`, `TimerTrigger` and `Trigger`, none of which touch Jackson (only event-pump's `config` package does). Module build with tests and `-Psourcecheck`: 36 tests, 0 failures. _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]
