feat: initial quarkus websocket solution

[ssala034]

Description Add new websocket client for another Java-Quarkus

Initial Solution for the Websocket Client using quarkus-websocket-next(https://quarkus.io/guides/websockets-next-tutorial) Includes:

• Templated client for postman-echo (will extend for slack API in future PR) - Returns a WebSocketclient.java - No WebsocketServer currently implement so cannot use Dev UI (future PR for server?)
• A connecter.java class to configure and open new WebSocket connections. - This is temporary because it is needed to test the client - Normally users would inject it in their business logic and then able to send message

No accompany tests for the template yet.

Screenshot of running client in exampleClient directory:

Related issue(s) Related to #1556

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 210247d66077a4e26ce1ed6463107c786febb77c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai[bot]]

Walkthrough

This change introduces a new Java Quarkus WebSocket client template, including configuration, React-based code generation components, and a full Maven project skeleton with supporting files. It also refactors test helpers and updates the helpers package to provide new utility functions. The listFiles utility is moved from utils to testing and its tests are relocated accordingly.

Changes

Files/Groups	Change Summary
package.json	Removed trailing newline character at EOF.
packages/helpers/src/index.js, packages/helpers/src/servers.js	Added and exported getServerHost; added and exported new test utilities from ./testing; moved listFiles export source from ./utils to ./testing.
packages/helpers/src/testing.js	New module: adds cleanTestResultPaths, getDirElementsRecursive, buildParams, verifyDirectoryStructure, and listFiles functions for test and file management.
packages/helpers/src/utils.js	Removed listFiles function and its export.
packages/helpers/test/testing.test.js	New test suite added for listFiles function, with mocked filesystem.
packages/helpers/test/utils.test.js	Removed all tests and mocks related to listFiles.
packages/templates/clients/websocket/test/integration-test/common-test.js	Refactored integration test helpers to use new directory structure verification and parameter builder utilities instead of manual file listing and snapshot testing.
packages/templates/clients/websocket/test/integration-test/integration.test.js	Replaced direct test result directory cleanup with cleanTestResultPaths; added java.quarkus nested config and corresponding test suite block for Java Quarkus client.
packages/templates/clients/websocket/java/quarkus/.ageneratorrc	Added new AsyncAPI generator configuration file for the Java Quarkus WebSocket client template with parameters for server selection and client naming, and excluded non-renderable files.
packages/templates/clients/websocket/java/quarkus/README.md	Added README with usage and testing instructions for the Java Quarkus WebSocket client template.
packages/templates/clients/websocket/java/quarkus/package.json	Added new package.json for the Java Quarkus WebSocket client template with dependencies, scripts, Jest and Babel configurations.
packages/templates/clients/websocket/java/quarkus/components/*	Added multiple new React components for Java code generation: ClientConnector, ClientFields, ConnectorFields, EchoWebSocket, HandleError, InitConnector, OnClose, OnOpen, OnTextMessageHandler, and dependency components.
packages/templates/clients/websocket/java/quarkus/template/*	Added complete Maven project template for Quarkus WebSocket client including Dockerfile, Maven wrapper scripts and properties, .gitignore, .dockerignore, pom.xml, JavaScript code generators for client and connector, Java model generator, and application properties.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~80 minutes

Possibly related PRs

• asyncapi/generator#1607: The main PR removes the listFiles function and its tests, while the retrieved PR adds tests for the same listFiles function, so their changes are directly related but opposite in intent regarding that utility function.
• asyncapi/generator#1485: The main PR adds a new .ageneratorrc configuration file specifically for the Java Quarkus WebSocket client template and updates the package.json dependencies, while the retrieved PR introduces support for .ageneratorrc files as an alternative to the generator section in package.json and modifies the generator to load configuration from .ageneratorrc if present; thus, the main PR’s addition of .ageneratorrc files directly utilizes the feature implemented in the retrieved PR.
• asyncapi/generator#1630: The main PR introduces a new Java Quarkus WebSocket client template with its own package.json, components, template files, and integration test setup, while the retrieved PR focuses on consolidating and refactoring integration tests for all websocket clients into a common test directory and helper functions to remove duplication; since the main PR adds a new template and its own integration test configuration that would benefit from the common test helpers and structure introduced in the retrieved PR, the changes are related at the integration test framework and structure level.

[!NOTE]

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

---

📜 Recent review details

Configuration used: .coderabbit.yaml Review profile: CHILL Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 93e70b8ad788391951005fc53477079ec376d441 and 210247d66077a4e26ce1ed6463107c786febb77c.

⛔ Files ignored due to path filters (2)

• package-lock.json is excluded by !**/package-lock.json
• packages/templates/clients/websocket/test/integration-test/__snapshots__/integration.test.js.snap is excluded by !**/*.snap

📒 Files selected for processing (1)

• package.json (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• package.json

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)

• GitHub Check: Test generator as dependency with Node 20
• GitHub Check: Acceptance tests for generated templates
• GitHub Check: Test NodeJS PR - ubuntu-latest
• GitHub Check: Test NodeJS PR - windows-latest
• GitHub Check: Test NodeJS PR - macos-13

✨ Finishing Touches

🧪 Generate unit tests

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

‼️ IMPORTANT Auto-reply has been disabled for this repository in the CodeRabbit settings. The CodeRabbit bot will not respond to your replies unless it is explicitly tagged.

• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[AayushSaini101]

@ssala034, why are there multiple Docker files? Kindly keep it simple for the first release, we can update it bit by bit

[ssala034]

@ssala034, why are there multiple Docker files? Kindly keep it simple for the first release, we can update it bit by bit

These docker files were given to me as part of the websocket-next started pack when I created a new project. So I assume they are ready to go.

In terms of their purpose, The .native one is for native compilation and the other two is builds a container image that runs the Quarkus app in JVM mode (.jvm). And the .legacy-jar is for backward compatibility with older Quarkus packaging.

But I see you POV, I will just keep the .jvm Dockerfile for now.

[AayushSaini101]

@ssala034 Can you tell me the steps on how we can generate output using the spec packages/templates/clients/websocket/java/quarkus/test/modeltest.yml ? and what is the use of https://github.com/asyncapi/generator/pull/1623/files#diff-5b7a736a4ed49d47b91ad4c04c74f1ab062d18f83f52074e8795559ef1f7157e the hardocre generated output

[ssala034]

@ssala034 Can you tell me the steps on how we can generate output using the spec packages/templates/clients/websocket/java/quarkus/test/modeltest.yml ? and what is the use of https://github.com/asyncapi/generator/pull/1623/files#diff-5b7a736a4ed49d47b91ad4c04c74f1ab062d18f83f52074e8795559ef1f7157e the hardocre generated output

To generate an output as in outputClient you can follow the steps I put in the README.md (packages/templates/clients/websocket/java/quarkus/README.md)

As for the hardcore generate output, I thought it would be nice to show you folks how it would suppose to look like as you are generating the output yourselves.

[AayushSaini101]

@ssala034 can you resolve the conflicts ?

[ssala034]

@ssala034 can you resolve the conflicts ?

@AayushSaini101 I was able to resolve conflicts and merge master.

[AayushSaini101]

@ssala034 kindly make it more generic instead of creating many component classes, kindly make it simple so that it is easy for the understanding purpose we can use onBinaryMessageHandler or onTextMessageHandler why we have different types of handlers, we can create a generic or simple one that we can consider thanks

[ssala034]

@ssala034 kindly make it more generic instead of creating many component classes, kindly make it simple so that it is easy for the understanding purpose we can use onBinaryMessageHandler or onTextMessageHandler why we have different types of handlers, we can create a generic or simple one that we can consider thanks

@AayushSaini101 I will remove the binary handler and only use the text handler to make it simple.

However, the other component classes are needed so I can create the template. Should I combined some of the templates components into one.

[ssala034]

@AayushSaini101 I update the template by removing the onBinaryHandler. I also added integration test since its important to have them and @derberg suggested it. Since I added the integration tests, there was no need for the hardcore outputClient since the user can see it when they do npm run test:update. I update the readme to tell them how to do so.

[AayushSaini101]

@ssala034 which version of the asyncapi does this template supports ? can you share the asyncapi document format for the testing purpose thanks : )

[ssala034]

@ssala034 which version of the asyncapi does this template supports ? can you share the asyncapi document format for the testing purpose thanks : )

@AayushSaini101 The template supports version 3.0.0. The latest version. The document's format I have been using for testing purposes are in packages/templates/clients/websocket/test/fixtures (ex: https://github.com/asyncapi/generator/blob/master/packages/templates/clients/websocket/test/fixtures/asyncapi-postman-echo.yml)

[Adi-204]

@ssala034 it would be nice if you can also keep track of follow-up issues like adding test for helpers, components with condition etc.

[ssala034]

@ssala034 it would be nice if you can also keep track of follow-up issues like adding test for helpers, components with condition etc.

@Adi-204 I am okay with putting those helper changes for the tests as you mentioned above. Should I then leave the current implementation inside the common-test.js and integration-test.js files for now, then when we merge the changes I create smaller PR to move them to a helper file? I could also make issue for them so we don't forget. Or do said above in this PR?

Similarly for the getServerHost() function.

[Adi-204]

@Adi-204 I am okay with putting those helper changes for the tests as you mentioned above. Should I then leave the current implementation inside the common-test.js and integration-test.js files for now, then when we merge the changes I create smaller PR to move them to a helper file? I could also make issue for them so we don't forget. Or do said above in this PR?

Similarly for the getServerHost() function.

@ssala034 I would suggest to create helpers with nice error messages in this PR only and testing we can open several follow-up issues. Testing can be done by other contributors also.

[AayushSaini101]

@ssala034 kindly resolve the comments so that we can review again thanks

[ssala034]

@ssala034 kindly resolve the comments so that we can review again thanks

Hey @AayushSaini101, I took another look and I am sure that I edited all comments mentioned by you folks already. Could you point out which comments I did not resolve yet, I couldn't find it.

[derberg]

I changed the title of the PR to chore: initial quarkus websocket solution as we are not releasing it yet

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[derberg]

/rtm