Contents
Overview
In ClearOrbit / TAKE production, search operations across multiple modules (commonly Purchase Orders, Shipments, and Packages/Packagers) may fail with a banner error indicating a missing request parameter named operation.
This occurs when the backend handler expects an operation parameter for the request (for example, /shipping/findShipment), but the UI/form submission does not include it—often due to cached/stale UI resources or a recent UI/configuration change (including label/action text changes with leading/trailing whitespace) that breaks form-to-controller binding.
Solution
Error message (exact)
javax.servlet.ServletException: Request[/shipping/findShipment] does not contain handler parameter named 'operation'. This may be caused by whitespace in the label text.
Symptoms
- Users cannot search or retrieve results across multiple areas (commonly: Purchase Orders, Shipments, Packages/Packagers).
- The error is often triggered by a Search action (example request path shown in the message:
/shipping/findShipment). - Impact is typically broad (multiple modules), suggesting a shared UI/search component issue rather than a single record/data problem.
What the error usually means
The server received a request to a controller/handler (e.g., /shipping/findShipment) that expects a handler parameter named operation, but that parameter was not included in the request payload. This is consistent with:
- Stale/cached UI assets causing the browser to submit an older or incompatible form.
- UI/config changes where label/action text (including leading/trailing whitespace) no longer matches what the backend mapping expects, so
operationis not populated.
Troubleshooting and mitigation steps
1) Confirm whether it is session- or browser-specific
- Reproduce the issue with:
- a different user account, and
- a different browser (or a private/incognito window).
- If it works in a clean session, the cause is likely cached UI resources or cookies tied to the original session.
2) Eliminate client-side cache as a factor (fastest safe check)
On an affected workstation:
- Hard refresh the application page:
- Windows:
Ctrl + F5 - macOS (varies by browser): use a hard refresh / “Empty cache and hard reload”
- Windows:
- If still failing:
- Clear site data for
your_instance.domain.com(cached images/files + cookies). - Sign in again.
- Clear site data for
- Re-test the same Search action (e.g., Search Shipments) and confirm whether searches now work across modules.
3) Check for recent UI/config changes that could break “operation” posting
If the issue started suddenly (for example, after a deployment window):
- Compare the most recently deployed UI/config artifacts to the last known-good version.
- Focus on shared search components and shipping/search screens.
- Look specifically for:
- Label/action text changes containing leading/trailing spaces
- Renamed “Search” buttons/actions
- Customizations that alter form field names or prevent
operationfrom being submitted
4) Isolate scope: navigation vs. search
Confirm whether:
- Users can open modules/screens successfully, but
- any Search action triggers the
ServletException
If only Search fails (across multiple modules), it strongly suggests a shared component/controller binding mismatch.
5) If Steps 1–2 do not resolve: validate deployment alignment or roll back
When cache/session clearing does not help, the remaining common causes are:
- UI/config package and backend controller expectations are out of sync
- A misaligned or partial deployment
Mitigation approach:
- Restore/roll back to the last known-good application/config package (per your change management process).
- Re-test searches across affected modules.
6) Collect JBoss server logs for root-cause confirmation
Gather the server-side logs from your JBoss host for the timeframe when the error occurs, then correlate:
- Request path (e.g.,
/shipping/findShipment) - The missing parameter (
operation) - Any related mapping or binding errors around the search request
Additional note
In at least one reported production outage with this exact error, the environment was later restored by customer-side actions; however, the specific remediation steps were not recorded, so the applied fix is unknown and the guidance above was not explicitly confirmed as the final resolution.
Verification
After applying a change (cache clear, config correction, rollback, redeploy):
- Log in with a standard user.
- Run searches in multiple modules (Shipments, Purchase Orders, Packages/Packagers).
- Confirm:
- Search results return normally
- The error banner no longer appears
Frequently Asked Questions
- 1. How do I know I’m hitting this specific issue?
-
You will see the exact error banner:
javax.servlet.ServletException: Request[/shipping/findShipment] does not contain handler parameter named 'operation'. This may be caused by whitespace in the label text.Searches will fail (often across multiple modules, not just one screen).
- 2. Why would this affect multiple modules (Purchase Orders, Shipments, Packages) at the same time?
-
When multiple modules fail on Search, it usually indicates a shared UI/search component or common form-to-controller binding has changed or is being served inconsistently (for example, cached UI assets or a recent UI/config deployment that introduced a mismatch).
- 3. What is the fastest safe thing to try first in production?
-
Rule out client-side caching: hard refresh, then clear site data (cache + cookies) for your instance URL and sign in again. If the issue disappears in an incognito/private window, it strongly points to cached resources/session data.
- 4. The error message mentions “whitespace in the label text.” What should I check?
-
Review recent UI/config changes for search-related labels/actions—especially leading/trailing spaces or renamed actions tied to “Search.” These can prevent the expected
operationparameter from being posted to the backend handler. - 5. What if clearing cache and cookies doesn’t help?
-
Treat it as a deployment alignment issue: verify that the currently deployed UI/config package matches backend expectations. If you have a known-good package from before the outage window, roll back/restore it and re-test. Collect JBoss logs during a failing search to confirm the mismatch.
Priyanka Bhotika
Comments