KAFKADATA

NEU

KAFKADATA

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

NEU

WIP

WIP

WIP:TODO

WIP:compiles!

WIP

WIP

WIP

WIP

WIP

WIP

WIP:exception

WIP

WIP

WIP

WIP

WIP

WIP

WIP

WIP

WIP

WIP

WIP

refactor: `ChatRoomFactory` returns real `ChatRoom`s

- `ChatHomeService` only deals with real `ChatRoom`s.
- Hence, there is no need for `ChatRoomFactory`, to return the simplified
  interface `ChatRoomInfo`.
- This is, because the implementation specific logic is implemented in the
  `ChatHomeService`, not `ChatHome` itself: the actual implementation is
  hidden behind that service (and behind the service `ChatRoomService` in
  the domain-class `ChatRoom`).

test: Proofed, that there is an NPE in `ShardedChatHome.getChatRoom()`

- Refined `AbstractConfigurationIT` to show, that an NPE can occure in
  `ShardedChatHome.getChatRoom()`.
- Defined the expected behaviour, if the NPE is handled correctly in the
  refined integration-test.

refactor: Refined the creation of new `ChatRoom`s

- Dropped `ChatHomeService.putChatRoom(ChatRoom)`.
- `ChatRoomFactory.create(UUID, String)` returns `ChatRoomInfo`.

refactor: DRY for the configuration of the `AbstractStorageStrategyIT`

refactor: Refined the configuration of `AbstractStorageStrategyIT'

refactor: `ChatRoomService.persistMessage(..)` returns a `Mono<Message>`

refactor: Simplified the handling of `MessageMutationException`

test: Added a test that assers disjunct chatrooms

chore: Added a Docker-Build

feat: Reintroduced `ChatRoom.shard`, becaus it is needed as a routing-hint

- Technically, the attribute is not needed.
- But, to implement the gua/sha-pattern, it is needed as routing-hing.
- Hence, it is reintroduced here and also added to the `ChatRoomTo` to
  be send to the client.

fix: Fixed a NPE in `ShardedChatHome.getChatRooms()`

- When collecting the `ChatRoom`s for all shards, unused shards with a
  `null` value were not skipped.
- Also added log-messages of level `INFO` for the creation of `ChatRoom`,
  `SimpleChatHome` and `ShardedChatHome`.

fix: Removed unnecessary generic in `ChatHomeService`

chore: Switched the default-configuration to sharding `none`

refactor: A `ChatRoom` does not have to remember its shard any more

- The shard of a `ChatRoom` can be derived from its ID, if the configured
  `ShardingStrategy` is known.
- Because the `ShardingStrategy` is known everywhere, where the shard of a
  `ChatRoom` is needed, it always can be derived dynamically.

refactor: Pulled business-logic into class `ShardedChatHome`

- Pulled the logic that selects the appropriate shard from the class
  `ChatBackendController` into the newly introduced class
  `ShardedChatHome`.
- Simplified the configuration
  - `InMemoryServicesConfiguration` creates a `ChatHome` of type
    `SimpleChatHome`, if the `sharding-strategy` `none` is choosen.
  - In that case, the values for `num-shards` and `owned-shards` are
    ignored and set to `1` and `0`.
  - If the `sharding-strategy` is set to `kafkalike`, a `ChatHome` of
    type `ShardedChatHome` is instanciated and the configuration
    respects the configured sharding.
- Simplified the configuration of `ChatBackendControllerTest` accordingly.

refactor: Made `SimpleChatHome` an implementation of `ChatHome`

refactor: Removed `ChatHomeFactory`

- `ChatHomeFactory` was only used during initialization.
- By moving the instanciation of `chatHomes` into the implementation-
  specific configuration, the necessity of the factory vanished.

feat: Introduced a kafka-like `ShardingStrategy` for `inmemory`

- Introduced the `ShardingStrategy`, that picks a shard for a given
  `ChatRoom`-ID.
  - Implemented a `KafkaLikeShardingStrategy`, that reuses the hashing
    algorithm, that is implementd in `Utils.murmur2()` in the
    `org.apache.kafka:kafka-clients` library.
  - The attribute `shard` of the `ChatHome` has to be restored according
    to the configured `ShardingStrategy` when loading the state - it must
    not be safed with the stored data, because it might change due to
    configuration-changes.
- The `ChatBackendController` was not configured correctly, because it
  had consumed the single `ChatHome` from the old configuration as the
  only entry in its `ChatHome[]`-array.
  - Refined the application-properties: Introduced an inner subclass
    `InMemoryServicesProperties` of `ChatBackendProperties`, that
    encapsulates the properties, that only concern the implementation
    `inmemory`.
  - Added the configuration-parameters `numShards` and `ownedShards`,
    that are needed by `inmemory`, to handle the sharding correctly.
- Introduced `ChatHomeFactory`, because the `ChatHome`s are instanciated
  by `ChatBackendConfiguration`, which is not aware of the configured
  implementation.
- Adjusted the test-cases to the changes.
- Added `InMemoryWithFilesAndShardingConfigurationIT`, that asserts,
  that the application works as expected, if sharding is activated.

test: Streamlined the config-IT, so that they use the same expectations

- Both tests now use the same data and expect the same results.
- Moved the actual tests and assertions to `AbstractConfigurationIT`.
- Also streamlined `AbstractStorageStrategyIT`, so that it produces
  the exact same data, that the configuration-tests are expecting.
  This is not a necessary change to get the refined coniguration-tests
  running. It just makes it easier, to produce the needed test-data for
  future refinements.
- Also streamlined the naming of the directory, where
  `InMemoryWithFilesStorageIT` stores its data.

refactor: Tried to simplify & clearify the naming of the integration-tests

refactor: DRY für shard-selection

feat: Prepared the application for sharding

- The `ChatBackendController` stores the `ChatHome`s in an array.
- Reintroduced a `ChatRoomFactory`

test: Added integration-test `InMemoryWithMongoDbStorageIT`

fix: Supressed mongo-autoconfiguration if `FilesStorageStrategy` is active

refactor: Renamed the test to `InMemoryWithFilesStorageIT`

feat: Refined `ChatBackendApplicationTest`

- Switched to a full server-startup (no MockMvc).
- Added some requests, that check the availability of the expected data.

refactor: refined the endpoint-uri's

feat: Introduced config switches to choose the used implementations

- Switched the existing `@Configuration`-classes into an auto-configuration.
- Added a `@ConditionalOnProperty`, that loades the default-configuration.
- Added an Auto-Configuration for the `MongoDbStorageStrategy`, which is
  inactive by default and can be switched on by the property
  `chat.backend.storage` to `mongodb`.

feat: configuration for service & storage lives in the according packages

test: Activated the maven-failsafe-plugin

fix: Added constraints for valid usernames

- This fix is necessary, because not all usernames can be stored in
  the newly introduced `MongoDbStorageStrategy`.

feat: Implemented and tested `MongoDbStorageStrategy`

- Beware: The version 4.0.0 of Spring Data MongoDB that is included in
  Spring Boot 3.0.x does not work with version 4.8.1 of the MongoDB drivers
  that are included. Therefore, the version of the drivers was downgraded
  to 4.7.2 - See:
  https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/#compatibility.matrix
- Also tried an upgrade of Spring Boot from 3.0.0 to 3.0.1, but without
  luck.
- Beware: Spring Boot 3.x does not include an autoconfigured embedded
  version of MongoDB for testing. It removed the autoconfiguration for
  `de.flapdoodle.embed:de.flapdoodle.embed.mongo` !

refactor: Refined (simplified) `StorageStrategy`

refactor: Moved `FilesStorageStrategy` in its own package -- Rename

refactor: Moved `FilesStorageStrategy` in its own package -- Move

refactor: `FileStorageStrategy` is not bound to `InMemoryChatRoomService`

refactor: Moved classes in package `persistence` in sub-packages -- Rename

refactor: Moved classes in package `persistence` in sub-packages -- Move

refactor: Introduced `AbstractStorageStrategyIT` as base for more tests

- Moved the test-logic, that does not depend on implementation-details
  into an abstract base-class `AbstractStorageStrategyID`.
- `LocalJsonFilesStorageStrategyIT` extends this class and only instances
  for that specific implementation and the accompanying setup.

fix: `ChatBackendApplicationTest` cannot corrupt the real data anymore

- The test used the default storage-direcory.
- Because the app is sometimes aborted during the shutdown, this sometimes
  lead to corrupted data in the default storage-directory.
- The test now uses a predefined set of data underneath the build-directory.
- Also changed the name of the according property to `storage-directory`.

fix: Refined `ChatBackendControllerTest` and fixed a bug in `ChatRoom`

- Only `ChatHomeService` and `ChatRoomService` are mocked.
- This makes the test more robust, because there are less sources for
  false positives or wron negatives because of wrongly mocked behaviour.
- Aforementioned is proofed by an unnoticed bug, that was discoverd by
  the freshly refined test.

feat: Moved persistence-logic from `ChatHome` into `ChatHomeService`

- Aligned configuration and tests accordingly.
- Also fixed some camel-case typos.

refactor: Moved business-logic from `ChatRoomService` into `ChatRoom`

- Some essential business-logic -- the identification of mutated messages --
  was buried in `InMemoryChatRoomService`.
- This business-logic was moved into `ChatRoom`, becaus otherwise, it
  would have been necessary, to reproduce this logic in each and every
  new implementation of `ChatRoomService`, which would have been exhausting
  and errorprone.
- This allowed also cleaner code in `InMemoryChatRoomService`, that
  can focus on the persistence-logic.
- The implementation of `MessageMutationException` and the look of the
  accompanying problem-details hat to be refined accordingly.

fix: Asserted, that `ChatHome` acts, as expected, if asked for a `ChatRoom`

refactor: Streamlined the API of the services

- `ChatRoomService` and `ChatHomeService` both return only reactive types.
- The decission stems from the wish, to become reactive all the way from
  the client to the technical implementation of the backend-services.
- This faciliates the mapping of the results in `ChatBackendController`.
- The refactoring already simplified lots of code, where a `Flux` has
  to derived from the `Stream`, yielding a good feeling about the plan,
  that is pursued with this refactoring.
- The refactoring also lead to the decision that `UnknownChatroomException`
  realy is a business-logic-exception (that according refactoring was
  already performed in the previous commits, to ceap this commit clean).

refactor: `UnknownChatroomException` is a business-exception - Relocate

refactor: `UnknownChatroomException` is a business-exception - Move

fix: Fixed generated problem-details for mutated messages