davsclaus opened a new pull request, #28396:
URL: https://github.com/apache/camel/pull/28396
_Claude Code on behalf of davsclaus_
This group adds the catalog body types (CAMEL-24961) for the eleven
hazelcast components: hazelcast-instance, -list, -map, -multimap, -pncounter,
-queue, -replicatedmap, -ringbuffer, -seda, -set and -topic. Each scheme has
its own Endpoint class, which gets its own `@BodyTypes` annotation; the JSON it
generates and the catalog copy come with it. No doc page changes.
**What the catalog says now**
The operation is the CamelHazelcastOperationType header, or else the
defaultOperation option; the producer outputs are listed by defaultOperation.
Each description names the header that carries the key, index or query
(CamelHazelcastObjectId, CamelHazelcastObjectIndex, CamelHazelcastQuery,
CamelHazelcastDrainToCollection). A value to store is anything Hazelcast can
serialize; a stream and no body fail.
| Component | Consumer | Producer input | Producer output |
|---|---|---|---|
| hazelcast-map | the value for an added or updated entry, no body for
removed and evicted; the key in a header | the value to put | the value for get
(null when missing); `Boolean` for containsKey and containsValue; a Map for
getAll; a Collection for getKeys and query; unchanged for the writes |
| hazelcast-multimap | the value for added, no body for removed | the value
to put | a Collection for get; `Integer` for valueCount; `Boolean` for the
contains; unchanged for the writes |
| hazelcast-replicatedmap | as the map | the value to put | the value for
get; `Boolean` for the contains; unchanged for the writes |
| hazelcast-list, hazelcast-set | the `ItemEvent` (the item is
`${body.item}`) | the item, a Collection for addAll, removeAll and retainAll |
the item for get; the live collection for getAll; unchanged for the writes |
| hazelcast-queue | the `ItemEvent`; the item itself with
queueConsumerMode=poll | the item | unchanged for add (the default); the item
for poll, peek and take; `Integer` for remainingCapacity and drainTo |
| hazelcast-topic | the `com.hazelcast.topic.Message` (the object is
`${body.messageObject}`) | the object to publish | unchanged |
| hazelcast-ringbuffer | | the item | `Long` for add (the sequence),
capacity and remainingCapacity; the item for the reads |
| hazelcast-pncounter | | `any`: only getAndAdd reads the body, as a Long |
`Long`; unchanged for destroy |
| hazelcast-seda | the body that was put on the queue; one that is not
Serializable arrives as bytes | a Serializable body, or one that converts to
bytes | unchanged: the producer does not wait, also for InOut |
| hazelcast-instance | no body; the action, host and port are headers | | |
**Checked at runtime.** A throwaway test, not part of the PR, ran an
embedded Hazelcast 5.4 member on an isolated cluster with the default
serialization filter of Camel. It sent text, bytes, a stream, a file, a Map, a
List, a Serializable POJO, a POJO that is not Serializable, an Integer and no
body through every operation of every producer. It got real events on every
consumer, including a second member that joined and left for hazelcast-instance.
Not run:
- the expiry event of a map entry with a TTL (see the bugs below);
- a topic publish of a stream with remote members;
- readOnceHead on an empty ringbuffer.
**Choices**
- The default producer output is `unknown` where get gives what another
member stored, and byOption lists the operations whose result is known.
- Most schemes have no default operation, and the description says that the
producer fails without one.
- The inputs list the carriers that Hazelcast can serialize, rather than
`any`. The descriptions say which operations do not read the body.
- The consumer of hazelcast-seda lists carriers instead of `unchanged` as
seda does, because the body passes through Hazelcast serialization.
**Bugs found, not fixed here.** The JIRAs will follow.
- No CamelHazelcastOperationType header and no defaultOperation fail with a
NullPointerException (`"operation" is null`), not a clear error. This applies
to map, multimap, replicatedmap, list, set, ringbuffer and pncounter.
- **list:**
- get without the CamelHazelcastObjectIndex header fails with a
NullPointerException.
- getAll (also for set) gives the live Hazelcast collection, not a copy.
- **queue:**
- removeIf always fails with "remove() is not supported!" from the
iterator of the Hazelcast queue.
- drainTo without the CamelHazelcastDrainToCollection header passes null.
This was read from the code.
- **pncounter:** getAndAdd with no body fails with a NullPointerException.
- **seda:** a body that is neither Serializable nor convertible to bytes
fails with an unclear "Null item is not allowed!".
- **map consumer:** `CamelMapListener` does not implement
`EntryExpiredListener`, so the expiry of an entry with a TTL gives no event.
multimap and replicatedmap use `CamelEntryListener`, which handles it.
- **docs:**
- The intro of the replicatedmap page was copied from the instance page
("consume join/leave events").
- Its XML samples use the old header name `hazelcast.operation.type`.
**Local checks**
- camel-hazelcast builds, with no change to the generated files after the
build.
- The 11 catalog copies equal their module.
- camel-catalog, camel-yaml-dsl-validator and camel-jbang-core tests pass.
- The Endpoint and Component DSLs regenerate with no change.
🤖 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]
