Thank you for the pr @Mirciulica15. I believe this looks good. Can you address:

• kc.bat handling
• what about someone using an ipv6 address ::1 - would that require detecting / handling addresses enclosed in [] with an optional port?
• do you see a good place to add the new support to the documentation?

@shawkins Added support for IPv6, I will later look for a good place to put this in the docs.

As for the kc.bat script, I'd like to test my changes before committing. kc.sh was relatively easy to test by volume mounting in the container via

podman run -v "$(pwd)/kc.sh:/opt/keycloak/bin/kc.sh:ro" -p 8080:8080 -p 8087:8087 localhost/keycloak-fix-address:local start-dev --debug [::0]:8087

Do you have any advice for testing kc.bat? Thanks!

Do you have any advice for testing kc.bat? Thanks!

I've locally used wine, but it doesn't always faithfully reproduce. cc @Pepo48 do you have any advise on windows testing?

We can always try to have someone on the keycloak team round out the pr for the kc.bat handling once we're set on the kc.sh logic.

Thank you for the update. Hopefully updating kc.bat won't be so bad now.

@Mirciulica15 cc:@shawkins with regards to testing kc.bat I'm afraid that I can only offer the obvious options - windows bare metal, VM or eventually a container (for non UI test cases).

We typically use mix of all - win-server VMs in our internal pipelines and containers in Github CI for the testsuite execution; and I can certainly test the PR even on my physical machine, as Steve already mentioned.

@Pepo48 I managed to get a hold of a Windows machine for testing, but I am facing several issues while trying to implement the regexes in the .bat script. For example, a one-liner like the one below works perfectly when I test it in my terminal, but always fails within the kc.bat script:

echo 127.0.0.1 | findstr /R /X "^[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*$" >nul && echo validIPv4 || echo notIPv4

I've tried changing the file encoding according to certain threads I have found, but the issue persists. Have you encountered this issue previously?

EDIT: The kc.bat script appears to become increasingly long and complex, especially with these latest changes. Echoing @shawkins's previous concerns about the complexity in the .bat script, do you think that migrating it to a more modern/maintainable alternative could be considered?

@Mirciulica15 I guess that by a modern alternative you mean PowerShell, right?

It's not on our radar right now, since there hasn't been a demand for it. The main concern is about maintainability - we don't want to maintain two separate scripts for one platform. On top of that, there might be still some users, who are running their instances within environments, where PowerShell is not/can't be installed.

In other words, guaranteed availability + non-existing demand for a change are the main reasons, why the bat script is still used.
There is probably a higher chance that both scripts will be replaced by a native Quarkus launcher in the future.

Regardless, feel free to open a discussion if you consider it to be important. It may raise some attention from the community and get some serious consideration.

@Mirciulica15 regarding the regex, my initial guess it that this may be caused by Windows findstr - it has known issues with the end anchor $ when used with piped input.

A simple demonstration of this limitation would be:

If you remove $ sign, it should work.

Unfortunately, in order to validate that nothing comes after the expected pattern I haven't found any other way than just a string manipulation:

@echo off
set "ip=127.0.0.1"
echo %ip% | findstr /R "^[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*" >nul
if %errorlevel% equ 0 (
    for /f "tokens=1-4 delims=." %%a in ("%ip%") do (
        if "%ip%" equ "%%a.%%b.%%c.%%d" (echo validIPv4) else (echo notIPv4)
    )
) else (
    echo notIPv4
)

(findstr /X means exact match, you should not need it since anchors are used)

Let me know if it solves something for you. Thanks!

Approved the workflow run for the kc.sh change to validate it's working as expected.

Hopefully kc.bat won't be too burdensome to update.

@Mirciulica15 Please fetch the latest changes from the main branch, as it should resolve the Windows issues in the CI. Thanks!

EDIT: Ahh, ok... I was probably able to do that :)

Sorry for the delay guys, I've been busy with my final exams these past few weeks.

Thanks for the tips @Pepo48, I worked on the kc.bat script a bit today and implemented the logic, trying to stay as close to kc.sh as possible. I tried the %errorlevel% approach, but I decided to use a different method with boolean operator chaining. I did some local tests and it seems to work, but I will take another look later today. Let me know if this looks like the right path to go down to.

Thank you for the pr @Mirciulica15. I believe this looks good. Can you address:

• kc.bat handling
• what about someone using an ipv6 address ::1 - would that require detecting / handling addresses enclosed in [] with an optional port?
• do you see a good place to add the new support to the documentation?

@shawkins I have added the new support for the --debug parameter in quarkus/CONTRIBUTING.md, this is the best place where I've seen this parameter detailed. Let me know if it looks ok, thanks!

@shawkins I have added the new support for the --debug parameter in quarkus/CONTRIBUTING.md, this is the best place where I've seen this parameter detailed. Let me know if it looks ok, thanks!

That looks good to me. Thank you!

@vmuzikar @Pepo48 @mabartos I don't have a problem with this getting into 26.3, can you have a look?

@Mirciulica15 thanks for the contribution! I just rechecked the Windows part - syntactically, everything looks good. Functionality-wise, I was able to run Keycloak in the debug mode with a specific debug address, attach the debugger, and hit the expected breakpoint, so the behavior is as intended.

Therefore, I’m approving the PR. Great job!

cc: @vmuzikar @shawkins

Thanks a lot, @shawkins @Pepo48 @vmuzikar @mabartos ! This was my first ever contribution to an open source project, and you made it a very pleasant learning experience!

Looking forward to helping with other things in the future! 🎩

As the person who was originally bitten by the issue and reported it, thank you for working on this @Mirciulica15!

This was my first ever contribution to an open source project, and you made it a very pleasant learning experience!

Congratulations, you did a great job with feadback.

Hi, thanks for the work on this PR @Mirciulica15 👋

I think it may have introduced a regression when running Keycloak in Docker with remote debugging enabled.

With Keycloak 26.3.5, the following docker-compose.yml works as expected — the instance starts and the JDWP debugger listens on port 5005:

services:
  keycloak-26-3-5:
    image: quay.io/keycloak/keycloak:26.3.5
    container_name: keycloak-26-3-5
    ports:
      - "8056:8056"
      - "5005:5005"
    environment:
      KC_BOOTSTRAP_ADMIN_USERNAME: "admin"
      KC_BOOTSTRAP_ADMIN_PASSWORD: "admin"
      KC_HTTP_PORT: "8056"
      DEBUG: "true"
      DEBUG_PORT: "*:5005"
    command: ["start-dev"]

But with Keycloak 26.4.0 (after this PR was merged), using the same setup :

services:
  keycloak-26-4-0:
    image: quay.io/keycloak/keycloak:26.4.0
    container_name: keycloak-26-4-0
    ports:
      - "8056:8056"
      - "5005:5005"
    environment:
      KC_BOOTSTRAP_ADMIN_USERNAME: "admin"
      KC_BOOTSTRAP_ADMIN_PASSWORD: "admin"
      KC_HTTP_PORT: "8056"
      DEBUG: "true"
      DEBUG_PORT: "*:5005"
    command: ["start-dev"]

…the container fails to start with the following error:

ERROR: transport error 202: getaddrinfo: failed to parse address
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c:700]

This also happens with DEBUG_PORT="0.0.0.0:5005"

However, it does work with DEBUG_PORT=5005 (just the port number, without host binding).
It also works with only DEBUG: "true" (no DEBUG_PORT), which binds to the default port 8787.

Could you confirm if this is an unintended regression, or if the debug configuration syntax was changed intentionally and needs updating in the docs?

@tanguy-c please open this as a new issue. The problem is that the new logic is focused just on the cli argument and doesn't then handle when only the environment variables are used.