rmannibucau commented on PR #110: URL: https://github.com/apache/deltaspike/pull/110#issuecomment-1365782630
Well just the parsing side is not a lot of work, in particular cause we don't care about the perf enhancements a lib like that can bring (thinking to memory optimization/buffer/cache). That said a very valid option for me would be to not do a yaml module but a generic `Map<String, Object>` flattenization module, then the user would load the file as he wants (protected abstract Map<String, Object> load();` in the abstract `GenericMapModel` class) - including whatever yaml lib he uses - and we would flatten the map (visiting object and supporting most of common default types: map, list recursively but String, primitives, BigDecimal, BigInteger as scalars). This enables to not bring any drawback and still be a one liner (+spi file) for end user which is probably saner. The main issue with libs like that is the fact it enables mapping as well as generic deserialization - the only we care, right. The mapping (object) brings issues and CVE we don't want - actually we probbaly don't want to justify more than explaining we we can't exploit some of them. Can it be a compromise? Else +1 to implement our own light parser. -- 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. To unsubscribe, e-mail: dev-unsubscr...@deltaspike.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
