Yeah, that format and library is designed around Java in mind and Scala as
a downstream user (unlike most Lightbend things which are Scala-first).
On Mon, 5 Nov 2018 at 15:03, Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 2:02 PM Gary Gregory
> wrote:
>
> > On Mon, Nov 5, 2018 at 1:59 PM Matt Si
On Mon, Nov 5, 2018 at 2:02 PM Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 1:59 PM Matt Sicker wrote:
>
>> I like the HOCON format for duration values:
>> https://github.com/lightbend/config/blob/master/HOCON.md#duration-format
>
>
> That looks easy to map to Java TimeUnit.
>
I could see augme
On Mon, Nov 5, 2018 at 1:59 PM Matt Sicker wrote:
> I like the HOCON format for duration values:
> https://github.com/lightbend/config/blob/master/HOCON.md#duration-format
That looks easy to map to Java TimeUnit.
Gary
>
>
> On Mon, 5 Nov 2018 at 14:53, Gary Gregory wrote:
>
> > On Mon, Nov
I like the HOCON format for duration values:
https://github.com/lightbend/config/blob/master/HOCON.md#duration-format
On Mon, 5 Nov 2018 at 14:53, Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 1:50 PM Ralph Goers
> wrote:
>
> > I have no problem with this but would think it would be something we
On Mon, Nov 5, 2018 at 1:50 PM Ralph Goers
wrote:
> I have no problem with this but would think it would be something we would
> want to do in 3.0 and not 2.x. Rather than to keep introducing features to
> 2.x I’d like to concentrate a bit on figuring out what things really need
> to be changed f
On Mon, Nov 5, 2018 at 12:46 PM Matt Sicker wrote:
> The Duration format is just ISO-8601. Problem is that nobody uses that part
> of the spec. :)
>
We use ISO-8601 to configure some files at work and it works, but it's a
bit ugly. I'm OK supporting both formats even. I just want a better format
I have no problem with this but would think it would be something we would want
to do in 3.0 and not 2.x. Rather than to keep introducing features to 2.x I’d
like to concentrate a bit on figuring out what things really need to be changed
for a 3.0 release and adding new significant features ther
The Duration format is just ISO-8601. Problem is that nobody uses that part
of the spec. :)
On Mon, 5 Nov 2018 at 13:33, Gary Gregory wrote:
> On Mon, Nov 5, 2018 at 12:12 PM Carter Kozak wrote:
>
> > Big +1 for values with units.
> > Unless we need to support this on 2.x, should we take advant
I agree that we shouldn't use the Duration.parse functionality, but
perhaps we can define our own parser to convert strings into Duration
objects similar to the parse function in TimeValue. Thoughts?
On Mon, Nov 5, 2018 at 2:33 PM Gary Gregory wrote:
>
> On Mon, Nov 5, 2018 at 12:12 PM Carter Koza
On Mon, Nov 5, 2018 at 12:12 PM Carter Kozak wrote:
> Big +1 for values with units.
> Unless we need to support this on 2.x, should we take advantage of
> java 8 java.time.Duration as our value type, and only implement the
> parser ourselves?
>
I think that tracking as a Duration is OK. The only
Big +1 for values with units.
Unless we need to support this on 2.x, should we take advantage of
java 8 java.time.Duration as our value type, and only implement the
parser ourselves?
On Mon, Nov 5, 2018 at 1:54 PM Gary Gregory wrote:
>
> Hi All:
>
> Today in appenders like the JMS Appender you can
Hi All:
Today in appenders like the JMS Appender you can specify time values like
the setting reconnectIntervalMillis="5000"; same idea with the mysterious
Configuration monitorInterval which is specified in seconds (how would you
know that without digging in the docs? ;-)
What I'd like to see in
12 matches
Mail list logo
