Add generic, component-agnostic test-run REST endpoint - #1699
Merged
ashishvijaywargiya merged 3 commits intoAug 22, 2026
Merged
Conversation
…ror messages The runTestSuite service returned the raw test.api.enabled property name and value directly in the error response sent to REST callers when the test execution API was disabled, either globally or for a specific component. This exposed internal configuration details unnecessarily. Both messages now return generic text without the property name or value, while server-side logging still captures full detail for diagnostics.
…er-component gating The generic testruns.rest.xml endpoint supplies componentName as a URL path parameter, but REST attribute binding merges body/path/query/header sources onto the same context map, so a caller could still send an empty value (e.g. an empty query parameter) and reach an unscoped code path that used to only exist for internal callers. An empty componentName resolved to ComponentConfig.matchingComponentName as null, which matches every component - silently turning a per-component request into an unscoped sweep across every component's tests and bypassing the per-component test.api.enabled.<componentName> gate entirely. This is exactly the failure mode the now-deleted runScopedTestSuite wrapper used to fail closed against, but the guard was not carried over when the wrapper was replaced by the generic endpoint. runTestSuite now rejects a blank componentName outright, both javadoc/ service-description text reworded to describe what the URL path parameter actually guarantees (a non-blank value) versus what it doesn't (that the value can't be overridden to a different real component - which was never a concern this design needed to prevent, since the endpoint is deliberately generic).
ashishvijaywargiya
added a commit
to apache/ofbiz-plugins
that referenced
this pull request
Aug 22, 2026
…c testtools endpoint (#374) Deletes the per-component test-run REST wrapper pattern from example, ecommerce, assetmaint, lucene, and scrum: - the groovy wrapper class in each component (e.g. ExampleTestRunServices.groovy) - the two duplicated <service> definitions each wrapper needed, in each component's servicedef/services.xml - each component's own test-run *.rest.xml (for example, this is the TestRunResource block removed from its shared rest.xml, since that file also carries example's own business-service REST resource; for the other four it is the entire file, since they had nothing else in it) ecommerce's servicedef/services.xml and its ofbiz-component.xml service-resource entry are removed entirely - that file existed solely to declare the two now-deleted services. Why Superseded by a new, generic, framework-owned REST endpoint added in the companion ofbiz-framework pull request, which takes componentName as a URL path parameter and needs no per-component files at all. All five components' tests remain reachable, now via POST /rest/testtools/testruns/{componentName} GET /rest/testtools/testruns/{runId} instead of each component's own separately-branded URL. No changes to any component's actual test suites, Jupiter test classes, or testdef files - this is REST/service wiring only. Testing - gradlew classes testClasses passes after each component's change. - Full sweep against a running server: all five old branded URLs (example-rest, ecommerce-rest, assetmaint-rest, lucene-rest, scrum-rest) confirmed gone (404); all five components' real test suites confirmed passing end-to-end through the new generic endpoint. - Full testIntegration run across the whole codebase: 658/658 tests passing, zero regressions. Dependency on the companion pull request This should merge together with, or before, the companion ofbiz-framework pull request (apache/ofbiz-framework#1699). This PR removes the last callers of TestRunServices.runScopedTestSuite/getScopedTestRunStatus, which the framework PR deletes. Merging the framework PR first while these wrapper scripts are still present would leave them calling methods that no longer exist.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Title: Add generic, component-agnostic test-run REST endpoint
Adds a single REST endpoint, in framework/testtools, that can trigger and poll a testdef
test-suite run for any component:
POST /rest/testtools/testruns/{componentName}
GET /rest/testtools/testruns/{runId}
componentName is supplied as a URL path parameter and bound into the service context by the
REST framework's existing path-parameter mechanism - the same mechanism the GET operation's
{runId} already used. The endpoint wires directly to the runTestSuite/getTestRunStatus services
that already existed, unscoped, in framework/testtools/servicedef/services.xml.
Why
This replaces a per-component pattern (see the companion ofbiz-plugins pull request (apache/ofbiz-plugins#374)) that
required copy-pasting a groovy wrapper class, two duplicated definitions, and a
component-owned *.rest.xml into every adopting component, purely to hard-code that one
component's name. The generic endpoint needs zero new files for any current or future component
that already has a real test-suite.
TestRunServices.runScopedTestSuite/getScopedTestRunStatus - the helper methods that existed only
to support the old per-component wrapper - are removed, along with their tests.
Security fix included
The endpoint's componentName normally comes from the URL path, but REST attribute binding merges
body/path/query/header values onto the same context map, so a caller could previously send an
empty componentName (e.g. an empty query parameter) and bypass the per-component
test.api.enabled. toggle entirely, falling back to an unscoped sweep across every
component's tests. runTestSuite now rejects a blank componentName outright, restoring the
fail-closed behavior the old per-component wrapper always had.
Testing
new endpoint, confirmed PASSED status with the correct componentName reported; confirmed a
deliberately wrong testParams override produces the expected different failure, proving the
override reaches the underlying assertion; confirmed the old per-component URL naming pattern
is not a real route.
Dependency on the companion pull request
This should merge together with, or after, the companion ofbiz-plugins pull request (apache/ofbiz-plugins#374). That PR
deletes the wrapper scripts that call runScopedTestSuite/getScopedTestRunStatus - merging this
PR first while those scripts are still present would leave them calling methods that no longer
exist.