I can't remember why we did it. Maybe Anatole can help with an answer?
Am 04.02.18 um 23:22 schrieb William Lieurance:
Hi devs,
I noticed the other day that the BigInteger converter is doing its own parsing of
hexadecimal strings at
https://github.com/apache/incubator-tamaya/blob/db56ee2264f
Hi devs,
I noticed the other day that the BigInteger converter is doing its own parsing
of hexadecimal strings at
https://github.com/apache/incubator-tamaya/blob/db56ee2264f79bb939cb4117c26d3d48d618f1d4/code/core/src/main/java/org/apache/tamaya/core/internal/converters/BigIntegerConverter.java#L
+1
The JSR actually will only support one single Converter instance per type,
whereas Tamaya supports multiple converters. Consequently there is no
constraint regarding converter ordering.
Additionally the fix make definitely sense for me from a usage perspective.
2018-02-04 20:10 GMT+01:00 P. Ott
Am 03.02.2018 um 21:21 schrieb Anatole Tresch:
> By now all modules in core, extensions AND sandbox are compiling and
> working and all tests are migrated as well.
+1
cool news -
are there any official artifacts available to build against?
Otherwise I wouldn't want to make the change yet, as the
Hi,
interesting bug you spotted :-)
@Anatole: does the configJSR say anything about an order?
To my mind keeping the order (FIFO) seems logically but I wouldn't want
to break compatibility with the coming JSR
Apart from that: +1 since it's more natural and maybe we should enhance
the javad
