fix(templates): the BPM starter's form calls its client-Java service

[delchev]

Master's nightly is red (run 31290954773) — BPMStarterTemplateIT.testCreateProjectFromTemplate fails on both the H2 and the PostgreSQL leg (243 tests, 1 failure), so it is deterministic, not a flake. The 8 Aug nightly was green; the regression is #6619.

That PR migrated the BPM starter's two TypeScript files to client Java, but left everything that talks to them pointing at the retired TypeScript — so the shipped sample does not work at all.

Three things were broken

1. The form posted to a deleted file. It called /services/ts/<project>/api/ProcessService.ts/processes, which feat(templates): client-Java process handlers for template-bpm (#6584) #6619 removed, and branched on response.status != 202 — the status the TS service used to set, where a client-Java @Controller answers 200. That is exactly the failure the nightly reports: the alert reads Unable to trigger a new process: 'undefined' (the error branch prints response.message, which the form-builder's $http shim never sets). It now posts to /services/java/${projectName}/${javaPackageName}/ProcessService/processes, and since that shim rejects on a non-2xx, it uses a proper error callback rather than an exact-status branch — which also gives the failure path a real message instead of undefined.
2. The service task's log line changed with the port (Process instance [id] with variables vs Process variables), and the test asserts on it. Restored, so the sample's observable behaviour is unchanged by the migration.
3. The test watched the wrong logger. console.log from the retired TypeScript task landed on app.out; the SDK logger nests the name it is given under app., so the Java task logs to app.<package>.MyServiceTask — which an appender bound to app.out never receives, and which logback-test.xml pins to ERROR. LogsAsserter only lowers the level of the logger it is handed, so the message was silently invisible: no error, just a 30-second timeout. It now watches the app tree, so it observes any client-application log and does not depend on the package name the template derives from the project.

(1) is what the nightly hit; (2) and (3) sat right behind it and would have failed the very next assertion.

Verified

Ran BPMStarterTemplateIT locally against the fix — green, and the process really runs end to end through the Java stack:

app.bpmtestproject.MyServiceTask - Hello World! Process variables: {param1=string-param-value, param2=777.0}

Also checked, while confirming the generated URL is right: ${JavaTask} survives Velocity (an undefined reference passes through — verified against the engine itself, so the BPMN's delegate expression is intact), JavaNames.toPackageName yields a single lower-case segment, and a client controller routes by FQN with dots→slashes.

🤖 Generated with Claude Code