JiriOndrusek commented on a change in pull request #5299:
URL: https://github.com/apache/camel/pull/5299#discussion_r607934362
##########
File path:
components/camel-jsonpath/src/main/java/org/apache/camel/jsonpath/JsonPathEngine.java
##########
@@ -182,14 +182,30 @@ private Object doRead(String path, Exchange exchange)
throws IOException, CamelE
return JsonPath.using(configuration).parse(list).read(path);
} else {
// can we find an adapter which can read the message body/header
- Object answer = readWithAdapter(path, exchange);
+ Object answer = null;
Review comment:
@davsclaus
There is no way, how to detect that adapter conversion fails in such case
(`vertx.Buffer` in this case). Unfortunately default adapter in case of
`vertx.Buffer` does not return `null` (which means - can not convert), but
return map{"bytes": ... "bytesBuff": ...}, which seems to be a valid conversion
with TRACE message.
> JacksonJsonAdapter converted object from: {} to: java.util.Map"
Execution of jsonpath fails afterwards, but without an option to detect why.
The only way of detecting "unknown" content (`vertx.Buffer` in this case) is
to try to convert content into `InputStream`. If conversion is successful, we
can go with the read method for the input stream.
But there is a small **back-compatibility issue**.
Let say, that there is an adapter, which maps InputStream into String
"InputStream:...text...".
Current state (before this PR) would return "InpuStream:...text..."
Fix with automatic conversion would change result to "...text...", because
automatic conversion would end successfully and would be used before the
adapter.
I agree that catching exception is a wrong way, which could cause more
problems, then I originally thought of.
So my opinion is:
1 - try conversion of exchange into inputStream
2 - if it succeeds, use inputStream for jsonpath
3 - if not, use adapter approach as a fallback
This solution brings a slight change in behavior (described above),
nevertheless I think that this should be the correct approach and the
difference could be mentioned in upgrade doc.
If user really needs to use older order (adpter and fallback to
inputStream), there are 2 options:
1 - user could remove converter from registry
2 - we can provide a property, which could return component to older behavior
WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
