-->

JSON Parser -java.lang.NoSuchFieldError: defaultRe

2019-02-10 10:42发布

问题:

I am using a JSON parser to extract the value and I am using the following jar json-path-2.1.0, and I am getting the following error when I invoke the use case deployed as webservice on weblogic server I wrote a small main program to extract the value from the json string and it works fine, but the server version of the use case is giving the issue. I am not sure if there are any other jars part of my ear can negatively impact this

SEVERE: defaultReader
java.lang.NoSuchFieldError: defaultReader
at com.jayway.jsonpath.spi.json.JsonSmartJsonProvider.<init>(JsonSmartJsonProvider.java:39)
at com.jayway.jsonpath.internal.DefaultsImpl.jsonProvider(DefaultsImpl.java:21)
at com.jayway.jsonpath.Configuration.defaultConfiguration(Configuration.java:174)
at com.jayway.jsonpath.internal.JsonContext.<init>(JsonContext.java:52)
at com.jayway.jsonpath.JsonPath.parse(JsonPath.java:596)

回答1:

Stumbled about the same problem.

The reason why it does not work is not the JDK 8. The reason why you encounter this issue, is the fact that weblogic 12.2.1.X is bundling some old version of json-smart.

On my machine this would be found here: jar:file:/C:/dev/WLS_12_2_1_2_0/oracle_common/modules/net.minidev.json-smart.jar!/net/minidev/json/JSONValue.class

Now if you are using a library like json-path that depends on json-smart, then by default the container will load the required class using one of its built-in modules.

The blowup you have, seems to be that the JSONValue class that your json-path depends on seemed to have this defaultReder field. Here is a snipet of the clode that is blowing up.

 public JsonSmartJsonProvider() {
        this(JSONParser.MODE_PERMISSIVE, JSONValue.defaultReader.DEFAULT_ORDERED);
    }

That

JSONValue.defaultReader

Seems not to be valid on weblogs older system class loader class.

You can tell the container to use what you are packing by putting into your weblogic.xml deployment descriptor something like this:

<wls:prefer-application-packages>       
<wls:package-name>net.minidev.json.*</wls:package-name>                              
</wls:prefer-application-packages>

I am having quite a bit of trouble getting weblogic to swallow the fine-grained instruction above. I found myself to force weblogic to swallog all that goes into the web-inf folder instead doing:

 <wls:container-descriptor>
        <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>        
    </wls:container-descriptor>

I would have rather not be using a hammer like the web-inf-classes, but I am dancing with the weblogic system classloader when I do not go coarse grained...

Regards.



回答2:

I too was facing this issue, It turned out some other library was using json-smart's older version, and it was getting precedence over json-path's json-smart dependency. Removing the other jar solved the issue. Or you can also downgrade your json-path's version to appropriate version such that it support json-smart's older version.



回答3:

Looks like JsonParser jar is present in JVM 1.8 version and it seems to have more precedence over the JsonParser class available in Json-path.jar. Apparently the us case doesn't work in 12.2.1 version of the weblogic server but it works fine in 12.1.3



回答4:

I had the same problem but I use Gradle so I had to add:

compile group: 'net.minidev', name: 'json-smart', version: '2.3' to my dependencies.