Forum Discussion
1 Reply
You’re hitting a known edge case: you’re trying to open a ReadyAPI project in SoapUI Open Source 5.7.1 (the 5.x line is SoapUI OS, not ReadyAPI). Projects that contain WS-Security config can throw
DefaultWssContainer.resolve(...) because "this.wssContainer" is null
during import/resolve. It’s a SoapUI OS bug/mismatch when a project created in ReadyAPI has WS-Security sections the OS resolver doesn’t initialize.
One of these should help:
- Open it in ReadyAPI (commercial) — not SoapUI OS.
ReadyAPI will upgrade the project in-place without that NPE. (There isn’t a “ReadyAPI 5.7.1.”) If your goal is to move forward on ReadyAPI, install a current ReadyAPI build and open the project there.
- If you must use SoapUI OS 5.7.1, strip WS-Security before import.
Open the project in your older ReadyAPI (or any version that loads it), then:
- Project > WS-Security: delete outgoing/incoming configs and cryptos used by the project.
- In each SOAP request: clear the Outgoing WSS assignment.
- Save, then import that trimmed project in SoapUI OS.
This avoids the OS resolver touching a missing wssContainer. Community threads reporting the exact NPE confirm the WS-Security container is the trigger.
- XML surgery (last resort, if you can’t open it anywhere):
- Make a backup.
- In the project XML, remove the <con:wssContainer ...>...</con:wssContainer> block under the project, and remove any request-level <con:outgoingWss>…</con:outgoingWss> references.
- Re-import into SoapUI OS, then recreate WSS locally.
(Do this only if you’re comfortable editing the XML; it’s the same object the resolver is choking on.) The WS-Security docs describe the elements you’ll be removing/adding back.
Let me know how it goes!