|
Right, but at the end of the day the core problem is how JSON serialization is implemented.
What we have is:
@Override
public synchronized Response getAllModulesDoc(final UriInfo uriInfo) {
final DefinitionNames definitionNames = new DefinitionNames();
final OpenApiObject doc = openApiGeneratorRFC8040.getAllModulesDoc(uriInfo, definitionNames);
return Response.ok(doc).build();
}
which then routes to JaxbContextResolver, which then uses ObjectMapper to turn OpenApiObject into JSON (and uses reflection to determine how to do that).
The problem is the fact OpenApiObject exists. It is the moral equivalent of doing Stream.collect() before doing further processing of the stream contents. You have to realize that on input there is EffectiveModelContext and on output there are bytes (which happen to represent a JSON a document).
Response.ok(doc) does this:
public static ResponseBuilder ok(Object entity) {
ResponseBuilder b = ok();
b.entity(entity);
return b;
}
and ResponseBuilder.entity() explicitly says:
So we really want to integrate at this level – e.g. provide an InputStream whose bytes are the JSON representation of what OpenApiObject models. At the end of the day, BaseYangOpenApiGenerator, needs to return an OpenApiInputStream from getFilledDoc() – the constructor of which just captures stuff from UriInfo and the EffectiveModelContext.
As for the implementation of said OpenApiInputStream, think of it as a more complicated java.util.Iterator. Essentially it iterates over EffectiveModelContext (maybe multiple times) and each time it gets a piece of the JSON document, which it caches internally and gives out its bytes on InputStream.read(). Whenever it runs out of bytes to give out, it moves to the next bit of EffectiveModelContext, turns it into a JSON fragment, and hands that out – until it runs out of EffectiveModelContext, at which point it reports -1 to indicate it is all done.
I think the core interface here ends up being https://www.javadoc.io/static/com.fasterxml.jackson.core/jackson-core/2.15.2/com/fasterxml/jackson/core/JsonGenerator.html, where the generator is pointed to something that holds bytes for OpenApiInputStream to consume and the EffectiveModelContext-processing logic is provided with the JsonGenerator to use methods writeStartObject() and similar. This obviously needs further investigation, but the goal is clear I think.
We already have stuff working on this general principle: see how https://github.com/opendaylight/yangtools/blob/master/model/yang-model-export/src/main/java/org/opendaylight/yangtools/yang/model/export/DeclaredStatementFormatter.java works once it is configured. toYangTextSnippet() takes either a module, or a submodule and returns an Iterable – and that in turn defers to https://github.com/opendaylight/yangtools/blob/master/model/yang-model-export/src/main/java/org/opendaylight/yangtools/yang/model/export/YangTextSnippetIterator.java – which converts a DeclaredStatement (and its subtree) to a sequence of Strings.
We want to do a similar thing, except:
- it is not DeclaredStatement tree but an EffectiveModelContext tree on input
- it is not YANG text snippets buts JSON snippet bytes on output
- the machinery is driven by a request for a byte
- there is Jackson in between
Perhaps a critical thing to understand: OpenApiInputStream here is consumed by framework is a similar fashion that YangTextSnippet users consume it. InputStream should be viewed as Interator<Integer>, where 'int read()' combines the function of hasNext() and next() (via the return of -1). Plus, obviously, it provides methods to consume bytes in bulk.
At the end of the day, there must be no ObjectMapper or com.fasterxml.jackson.annotation in sight.
Also, to drive this point home even more, think of EffectiveModelContext as a source of events (like "we have a module", "we have an RPC", "we have an RPC input", "we have a leaf", "we ended the RPC input", "we have ended the RPC", "we have ended the module") and we are turning them into JSON events (like beginObject(), endObject(), etc.) and then turning them into bytes. This is stream processing at its purest.
| 
Image Pasted at 2023-1-9 10-08.png
