I have a legacy system at hand. This system was using an old version of org.json.JSONObject. For this version the following json was valid
{
"key" = "value",
"key2": "value2"
}
The json is actually invalid but for this version it was valid.
Now I upgraded the version to the latest one and everything is failing because of =. I get error that Expected ':' at char XX everytime. I could change my local tests and integ tests but what about clients? I have no idea whether they pass = or : and knowing them they would be passing =.
Is there a way i make the latest version on JSONObject accept = as valid assignment and alternative to : or is this a lost cause?
Related
With Apache Camel (spring-boot) there was a change in how split handled non-array JSON objects around version 3.13.
Is there any way to "force" the 3.12 behaviour of split? (or get a similar result?)
When splitting the following JSON document:
{
"listOfthings": [
{
"thingA": { "Afield1": "Avalue1","Afield2": "Avalue2"},
"thingB": { "Bfield1": "Bvalue1","Bfield2": "Bvalue2"}
},
{
"thingA": {"Afield1": "Avalue3","Afield2": "Avalue4"},
"thingB": {"Bfield1": "Bvalue3","Bfield2": "Bvalue4"}
}
]
}
In camel version 3.12, the following code:
from("file://read/some/file.json")
.convertBodyTo(String.class)
.unmarshal().json()
.split(simple("${body.get('listOfthings')}"))
.split(simple("${body.get('thingA')}"))
.bean("processBodyBean");
The body that would go to processBodyBean was
{ Afield1: "Avalue1", Afield2: "Avalue2" }
{ Afield1: "Avalue3", Afield2: "Avalue4" }
in versions after 3.12 the body contains the field level key-value pair.
Afield1: "Avalue1"
Afield2: "Avalue2"
Afield1: "Avalue3"
Afield2: "Avalue4"
The "new" behaviour feels logically more accurate - so i'm sure this is not a "bug".
We started with a new project using camel and it was deployed around the time 3.12 was released. We unfortunately wrote it based on the 3.12 behaviour. It's not a major re-write, but it is a significant change to a production system - which has run flawlessly for months.
We are just considering our options before we re-write.
I need to generate classes based on provided swagger file. Unfortunately I have no influence on content of this file.
My config in gladle looks like:
task generateApi {
doLast {
def config = new CodegenConfigurator()
config.setInputSpec("file:///$projectDir/$swaggerSourceFile")
config.setOutputDir("$projectDir/$swaggerTargetFolder")
config.setLang('spring')
config.setAdditionalProperties([
'interfaceOnly' : true,
'apiPackage' : 'somepackage',
'modelPackage' : 'somepackage.domain',
'sourceFolder' : '',
'java8' : true,
'dateLibrary' : 'java8',
'skipDefaultInterface': true
])
new DefaultGenerator().opts(config.toClientOptInput()).generate()
}
}
Exception which I`m getting is : "error: constant string too long"
Problem is that even I set 'skipDefaultInterface', swagger will generates it. In default interface it generates default response entity body which is json file which is 70k char long string.
Please help!
Looks like this is a known issue with the spring generator in Swagger Codegen:
https://github.com/swagger-api/swagger-codegen/issues/9055
A PR for this issue is available but not yet merged (as of February 2020):
https://github.com/swagger-api/swagger-codegen/pull/8691
Try using openapi-generator v. 4.2.2 or later which is supposed to include a similar fix.
I've updated to elasticsearch java library version 5.2.0.
In 2.x,
I was using SearchRequestBuilder.addField() in order to add a field to the search request. Nevertheless, It seems to be replaced. I've written the available methods intellisense is showing me. Which of them do I need to pick?
addDocValueField
addFieldDataField
addScriptField
addStoredField
storedFields
fields
SearchRequestBuilder.setNoFields is also removed. Which would be the alternative?
Currently, I'm calling scripts from Java using this code. Is there any more elegant way to call it in 5.x Java API?
Code:
return AggregationBuilders
.terms(this.getName())
.field(this.getName())
.script(new Script(
ScriptType.FILE,
"painless",
"year",
ImmutableMap.of("field", this.getName())
)
);
As you can see I setting field as script parameter. Nevertheless, I don't quite understand how to get it from script code.
Thanks.
When in doubt, go to the source
use setFetchSource(String[] includes, String[] excludes) instead
use setFetchSource(false) instead
if you need to execute this script for each document, you can use addScriptField()
i update the opengl version.
But i got an error :
AWTGLPixelBuffer pixelBuffer = pixelBufferProvider.allocate(gl,
AWTGLPixelBuffer.awtPixelAttributesIntRGB3,
v.getWidth(),
v.getHeight(),
1,
true,
0);
My library could not find awtPixelAttributesIntRGB3 . If i use old version, it can find that.
I import the same library : import com.jogamp.opengl.util.awt.AWTGLPixelBuffer;
Last thing, i downloaded last version of opengl here (jogamp-all-platforms.7z) :
http://jogamp.org/deployment/jogamp-current/archive/
And i only add jogamp-all.jar to my lib folder.
Thanks in advice.
You give us very little information on what's going on.
E.g. we don't even know from what version to which new one you upgraded.
I guess your problem is that the field awtPixelAttributesIntRGB3 was removed from version 2.2 to 2.3.
The API documentation of GLPixelBuffer.GLPixelBufferProvider#allocate explains quite well how to use it.
The key is that you need to fetch pixelAttributes differently, e.g. via getAttributes(GL, int, boolean).
Came across a recent issue where user submitted string value 'null' is being stored into the data base as '"null"'. Basically double quotes are being added at the start and end of the String.
Investigation revealed that JSON-lib doesn't seem to handle the 'null' string value correctly. This is exhibited by the following test methods.
#Test
public void shouldHandleNullStringInJsonFormattedString() {
String jsonTest = "[\"null\",\"aValue\"]";
assertTrue(jsonTest.contains("\"null\""));
assertFalse(jsonTest.contains("\"\\\"null\\\"\""));
String convertedBack = JSONSerializer.toJSON(jsonTest).toString();
// fails at below line
assertFalse(convertedBack.contains("\"\\\"null\\\"\""));
}
#Test
public void shouldHandleNullStringLiteral() {
JSONArray jsonArray1 = JSONArray.fromObject(Arrays.asList(null,"b"));
JSONArray jsonArray2 = JSONArray.fromObject(Arrays.asList(JSONNull.getInstance(),"b"));
JSONArray jsonArray3 = JSONArray.fromObject(Arrays.asList("null","b"));
assertEquals("[null,\"b\"]", jsonArray1.toString());
assertEquals("[null,\"b\"]", jsonArray2.toString());
//fails at below line
assertEquals("[\"null\",\"b\"]", jsonArray3.toString());
}
basically when browser sends ["null", "aValue"] to server, JSON-lib changes it to ["\"null\"", "aValue"].
Also from the server side we are unable to construct a JSON formatted String like ["null", "b"] using JSONArray. JSON-lib does not seem to handle these two basic scenarios properly.
Have emailed to the mailing list and contact email addressed on their site but no response yet. It seems like someone has previously posted about this issue on
http://sourceforge.net/p/json-lib/discussion/587134/thread/faf83e9a/
But no response for that either.
Any body has any suggestions/fixes for this issue ?
We are using the latest version of json-lib i.e 2.4
Update
Looking at the source code of json lib net.sf.json.util.JSONUtils.mayBeJSON method is a bit weird.
public static boolean mayBeJSON( String string ) {
return string != null
&& ("null".equals( string )
|| (string.startsWith( "[" ) && string.endsWith( "]" )) || (string.startsWith( "{" ) && string.endsWith( "}" )));
}
Seems like any literal String value of 'null' is considered JSON ??
Any body has any suggestions/fixes for this issue ?
My suggestion would be to download and build the latest version from github ( project " aalmiray / Json-lib" ). Try the "master" branch first, then the "development" branch, and finally look at the various forks that exist.
If that doesn't give you an answer, create your own fork and develop a fix for yourself ... then send a pull request to get it incorporated.
Plan B would be to look for an alternative to json-lib where issues are fixed more rapidly. The owners of this project seem to be taking forever to deal with issues and act on merge requests.