Remo

refactoring is mostly complete, so this can be addressed. Should be a easy PR for TypeParser to also handle the date/time classes by looking for a static parse method.

why that? so far it does not call any parsing. The TypeParser and Jackson are/should not be related, they are used in different contexts. At some point TypeParser should also...

Not sure about the Jackson. Maybe yes, TypeParser could make use of it. Maybe at first trough a feature flag in KatharsisProperties to have the possibility to enable/disable it. PR...

> e.g.; java.util.Date type, in some filter, we need ignore day. 2009-01-21 equals 2009-01. that could be resolved with a custom "FilterOperator" (like eqYearMonth instead of eq). And the FilterOperator...

you can also just make use of @JsonApiResource(type="v1/users") and stick to one Katharsis instance. Ideally you make also use of QuerySpec and ResourceRepositoryV2 if you setup a new repository.

or try to avoid versioning, because in a hateoas setting with all the linking it is not that great. Support for @JsonView would maybe quite useful.

yes, seems that way. DefaultQuerySpecDeserializer.getAttributeType needs to check @JsonProperty on the attributes. To some part that information is available from resourceRegistry.getEntry(resoureClass).getResourceInformation() with ResourceField.getJsonName(). But that that does currently not provide...

temporarly workaround might be to set allowUnknownAttributes to true. PRs welcome :-)

last PR did fix code that was obsoleted by the refacotring, and fortunately, the refactoring itself already fixed the issue. A bit unfortunate, but happens rarely :-( Sorry for that....

ServiceDiscovery would be the way to go. All the reflections stuff should really just be used if no DI environment is around. I'm not familar with Guice regarding initialization behavior....