Bug Report - OpenAS2 4.8.3 Windows launcher scripts fail to start on a clean install

[wheelersf]

Greetings,

Claude Fable 5 found this while working with OpenAS2, so I asked it to create a bug report regarding the two items:

Project: OpenAS2 (https://github.com/OpenAS2/OpenAs2App)
Version: 4.8.3 (SourceForge binary distribution OpenAS2Server-4.8.3.zip)
OS: Windows 11 Pro (26100)
JDK: Eclipse Temurin 17.0.19 (installed to C:\Program Files\Eclipse Adoptium\jdk-17.0.19.10-hotspot)
Component: bin\start-openas2.bat, bin\find_java.bat

Summary

On a clean Windows install, bin\start-openas2.bat does not start the server. Two independent defects in the
shipped Windows batch scripts are involved. On a machine where JAVA_HOME is not set and Java is only reachable
via PATH, both are hit; each is sufficient on its own to prevent startup, and neither produces a useful error
message (no log file is created, because the JVM never really launches).

Both are Windows-only; the equivalent *.sh scripts are unaffected.

---

Bug 1 — start-openas2.bat: OPENAS2_LOG_DIR system property is missing its -D

File: bin\start-openas2.bat (line ~35)

Current code:

set EXTRA_PARMS=%EXTRA_PARMS% DOPENAS2_LOG_DIR="%OPENAS2_LOGGING_BASE%"

The token is DOPENAS2_LOG_DIR=... — it is missing the leading dash of the -D JVM flag. It should be
-DOPENAS2_LOG_DIR=... (this is the system property that config\logback.xml references as
${OPENAS2_LOG_DIR} in <file>${OPENAS2_LOG_DIR}/log-${byDay}.txt</file>).

Resulting Java command line (note the bare, non-option token before -cp):

java -Xms32m -Xmx384m DOPENAS2_LOG_DIR="...\logs" -cp <classpath> org.openas2.app.OpenAS2Server config.xml

Because DOPENAS2_LOG_DIR=... does not begin with -, the JVM treats it as the main-class name and stops
processing VM options. The launch fails immediately with:

Error: Could not find or load main class DOPENAS2_LOG_DIR=...\logs

No server starts and no log is written (logging is never initialized), which makes the failure hard to diagnose.

Fix: add the missing -:

- set EXTRA_PARMS=%EXTRA_PARMS% DOPENAS2_LOG_DIR="%OPENAS2_LOGGING_BASE%"
+ set EXTRA_PARMS=%EXTRA_PARMS% -DOPENAS2_LOG_DIR="%OPENAS2_LOGGING_BASE%"

---

Bug 2 — find_java.bat: variables are used after endlocal, breaking PATH-based Java discovery

File: bin\find_java.bat (lines ~19–44)

When neither JAVA nor JAVA_HOME is defined, the script falls through to discovering Java via where java.exe.
That code path is broken: found_count and java_list[] are assigned inside a setlocal/endlocal block but
consumed after endLocal, where endlocal has already discarded them.

Current code (abridged):

setlocal EnableDelayedExpansion
set java_list=
set found_count=0
for /F delims^=^ eol^= %%i in ('where java.exe') do (
  set /A found_count+=1
  for %%F in ("%%i") do set bin_folder=%%~dpF
  set java_folder=!bin_folder:~0,-5!
  call set java_list[%%found_count%%]="%%java_folder%%"
)
endLocal                                   &:: <-- discards found_count and java_list[]

if %found_count% GTR 1 (                   &:: %found_count% is now EMPTY here
  ...
)
if %found_count% EQU 0 goto JavaNotFound   &:: also empty -> malformed IF
echo Java install found: %java_list[1]%    &:: empty
set JAVA_HOME=%java_list[1]%               &:: empty

Symptom: with Java resolved only via PATH, the script does not set JAVA_HOME; instead it aborts with a
cryptic batch parse error:

1 was unexpected at this time.

(An empty %found_count% turns the following if %found_count% ... lines into malformed comparisons.) Notably,
even the intended "no Java found" path is broken: instead of the friendly No Java install found ... message, the
user gets the parse error above. The result is that start-openas2.bat (which does if %ERRORLEVEL% NEQ 0 exit /B 1
after calling find_java.bat) exits before Java ever runs.

Fix: consume the loop results before endlocal, and carry the one needed value across the endlocal barrier
with the standard endlocal & set "VAR=%inner%" idiom. For example:

setlocal EnableDelayedExpansion
set java_list=
set found_count=0
for /F "delims=" %%i in ('where java.exe 2^>nul') do (
  set /A found_count+=1
  for %%F in ("%%i") do set "bin_folder=%%~dpF"
  set "java_folder=!bin_folder:~0,-5!"
  set "java_list[!found_count!]=!java_folder!"
)
if !found_count! GTR 1 (
  echo More than 1 Java install found:
  for /L %%n in (1,1,!found_count!) do echo   %%n: !java_list[%%n]!
  echo Set JAVA_HOME to one of the above.
  endlocal & exit /B 1
)
if !found_count! EQU 0 ( endlocal & goto JavaNotFound )
endlocal & set "JAVA_HOME=%java_list[1]%"

(%java_list[1]% on the last line is expanded while still inside the setlocal scope, then endlocal runs, then
the outer JAVA_HOME is set — the classic pattern for exporting a value out of a setlocal block.)

---

Combined impact / severity

• Severity: high for Windows first-run — on a clean box with a PATH-only JDK (a very common state right after
  installing a JDK), the server cannot be started with the shipped scripts, and the errors are misleading (no log,
  "unexpected at this time", or "could not find main class").
• Users with JAVA_HOME already exported avoid Bug 2 (early goto :JavaHomeFound) but still hit Bug 1.

Reproduction

1. Clean Windows install of OpenAS2Server-4.8.3.zip.
2. Install a JDK 17 that is on PATH but do not set JAVA_HOME.
3. Run bin\start-openas2.bat → observe ... was unexpected at this time. and no server.
4. Set JAVA_HOME, run again → observe Error: Could not find or load main class DOPENAS2_LOG_DIR=... and no server.

Workaround we used

• Set JAVA_HOME in the launching environment (sidesteps Bug 2's where java.exe path).
• Insert the missing - on line 35 of start-openas2.bat (fixes Bug 1).

After both, OpenAS2 4.8.3 starts normally and completes a signed+encrypted AS2 round-trip with a partner (verified
against mendelson AS2 Community Edition), so the defects are isolated to the two Windows launcher scripts.

[uhurusurfa]

The missing dash was already fixed: #548

It is in 4.8.3 release.