missing required parameter 'document - service invoked from SOAPUI 5.4.0


From SOAPUI, we’re invoking services.
The jar in UAT environment is working fine.
The one we build in dev environment from the last checked source in SVN repository gives following error for the same request.

<webM:message xml:lang=“”>java.lang.Exception: missing required parameter ‘document’</webM:message>
<webM:stackTrace xml:lang=“”>com.wm.app.b2b.server.ServiceException: java.lang.Exception: missing required parameter ‘document’
at pub.xml.documentToXMLString(xml.java:1106)
at sun.reflect.GeneratedMethodAccessor249.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Server log showed java.lang.unsupportedclassversionerror while loading startup services.
So, specified lower version environment as target and the error is gone.

But we’re still getting the same exception.

UAT jar works in dev environment as well.

Tried decompiling uat jar and building again rom that source.
Still the same error.
Problem doesn’t seem with the source but the java bytecode.
The classes which form response document down the line may not be getting instantiated.

UAT java version is 1.7_67
Dev version is 1.8_25

These are unix boxes.

We’re using windows machine and Spring Tool Suite to build.
Jave version is 1.8_131.

Any help how to solve this error on windows machine as we need to modify source and build again?



Deep down in the code there was null pointer exception occurring.
So, document input was not getting constructed.



unsupportedclassversionerror usually indicates that you try to run java code compiled for a higher target version with a lower runtime version.

In your case the code was compiled for Java 8 which cannot be understood by Java 7.
When specifying Java 7 as target even when using Java 8 as compiler the resulting code will be working on Java 7, but you will not be able to use language features being introduced in Java 8 then. Compiler should give an appropriate warning then.


Yes, you’re right.

We’re to support many versions of deployed jars some of which were compiled with older versions and now runtime versions change.
In some cases, building with ant files generate version 52 (java 8) class files even after specifying lower target runtime
settings in Eclipse. Needed version is 51.
But if built young project->build commands, appropriate versions take effect.

Ant files have requisite version parameters for java properties.

Thanks for the response.