I was going to make the change but ran out of time...
No rush though, I just didn't want to forget about it and have it cause
issues later in the generated code. (I'll bring this - maintenance - up in
the other thread. )
On Wednesday, January 29, 2014, Ralph Goers
<rgo...@apache.org<javascript:_e({}, 'cvml', 'rgo...@apache.org');>>
wrote:
> I can do it but it won't be for another 8 hrs or so. If you need it sooner
> go ahead.
>
> Sent from my iPad
>
> On Jan 28, 2014, at 9:00 AM, Remko Popma <remko.po...@gmail.com> wrote:
>
> Who will make this change (getOrCreateLevel -> forName) ?
> I'm asking because I'm calling this method in the generated wrapper source
> code...
>
>
> On Mon, Jan 27, 2014 at 12:55 PM, Nick Williams <
> nicho...@nicholaswilliams.net> wrote:
>
> Okay. I'm good with "forName," then.
>
> N
>
> On Jan 26, 2014, at 9:51 PM, Ralph Goers wrote:
>
> I disagree - you are getting the Level that matches the name, so forName
> does describe what is happening.
>
> See the Javadoc on the second question. The intValue is ignored unless
> the Level is created. Yes, that could lead to some problems if there are
> conflicts, but I think returning the registered level is better than
> throwing an exception.
>
> Ralph
>
> On Jan 26, 2014, at 7:46 PM, Nick Williams <nicho...@nicholaswilliams.net>
> wrote:
>
> Level.forName wouldn't work--it's not just "for name," it's for the name
> /and/ the level. But it must be unique by the name.
>
> For that matter, what are we to do in the following situation?
>
> Level.getOrCreate("DIAG", 150);
> ...
> Level.getOrCreate("DIAG", 250);
>
> They're not going to get what they expect in both cases.
>
> Nick
>
> On Jan 26, 2014, at 9:28 PM, Matt Sicker wrote:
>
> How about Level.forName()?
>
>
> On 26 January 2014 21:06, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>
> No objections on spawning a separate thread for discussion 2.
>
> I also am not in love with the method name but it does describe what it
> does. If anyone has any ideas on a better name please suggest it (we are
> talking about the getOrCreateLevel method name).
>
> Ralph
>
> On Jan 26, 2014, at 6:59 PM, Nick Williams <nicho...@nicholaswilliams.net>
> wrote:
>
> There are two separate discussions going on here, so it's easy to get
> lost. We should probably split discussions again.
>
> Discussion 1: The finer details of custom levels. I'm fine with using a
> static factory method and making the constructor private, but I'm not a big
> fan of the name. Just sounds awkward. Unfortunately, I can't come up with
> anything better.
>
> Discussion 2: A wrapper / extended interface for logging using these
> custom levels. Yes, Paul, users can just do this:
>
> logger.log(MyCustomLevels.LEVEL1, "message");
>
> That is already supported by making Level extensible. However, some on the
> team have expressed a desire to make it even easier. Given hypothetical
> custom levels DIAG and NOTE, the following would be a "nice-to-have" as you
> call it:
>
> logger.note("message");
> logger.diag("message");
> etc.
>
> We're discussing options to make this possible. However, it is not a
> requirement to enable custom levels. Custom levels are now already possible.
>
> Any objections to breaking discussion 2 off into another thread?
>
> Nick
>
> On Jan 26, 2014, at 8:46 PM, Paul Benedict wrote:
>
> I got lost in the discussion. Can someone please clarify... Is the custom
> logging interface a nice-to-have or a requirement of the system?
>
> I was hoping
>
>
