Generate resolved schema from data about openapi4j HOT 3 CLOSED

Your request is described very clearly, thanks for that.

Unfortunately, we are far from validation processing here.
This would require assignements (which are seriously avoided when possible) during validation process for obvious overhead regarding performance.

This could be only useful when a discrimator is setup.

If I understand well, your final goal is to know how deserialize your input content in such case. Discriminator propertyName is key here.

Here're a sample approach which should do it nicely (untested):

@JsonTypeInfo(
  use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY,
  property="YOUR_DISCRIMINATOR_PROPERTY_NAME",
  visible = true /* important if you need to keep the property */)
@JsonSubTypes({
  @JsonSubTypes.Type(value = Dog.class, name = "Dog"),
  @JsonSubTypes.Type(value = Cat.class, name = "Cat")})
class Animal {
  public String name;
  @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy_MM_dd")
  public LocalDate birthDay;
  public String YOUR_DISCRIMINATOR_PROPERTY_NAME; // may be optional
  protected Animal() { }
}

class Dog extends Animal {
  public double bark;
  public Dog() { }
}

class Cat extends Animal {
  public int lives;
  public Cat() { }
}

For booleans, you can use setters or custom deserializer and/or Boolean object (0 and 1 recognized).

All in all, this much more deserialization coding than schema need in my opinion.

from openapi4j.

Unfortunately I am working with generic objects against generic schemas - they are not known ahead of time. It is essentially a 'proxy' that sits between the raw http requests and the resulting end points. The system marshals requests to the APIs, with the intent to use openapi spec to convert data types as needed.

The proposal wouldn't need to create a full schema or modify it on the fly. It could simply record the outcome of all 'decision points', such that the schema can be iterated correctly with respect to the data by using this 'decision point' structure.

One workaround could be to support adding a customer validator of "*.*" that is called for every keyword of every node (or possibly only the 'anyOf', 'oneOf' etc nodes).

I could then exploit this to store INFO validation results using the 'crumbs' + type info then delegate to the next/core validator. These hooks are quite powerful and can be exploited. I could then reconstruct the decision points by iterating the info validation results . Although I won't necessarily need the entire schema of the data - I only need a record of where certain data types and formats are.

from openapi4j.

Related to #79

from openapi4j.