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 simply someone could write this (pseudocode below):
>>>>>>>> logger.log(MyCustomLevels.LEVEL1, "message");
>>>>>>>>
>>>>>>>> ...so no different interface should be required, right? Can't someone
>>>>>>>> just pass in their log level directly without using one of the
>>>>>>>> named-log-level convenience methods?
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sun, Jan 26, 2014 at 8:37 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>>> Now Level can't be used in an annotation. Since it supports string
>>>>>>>>> names for levels, should I just use Level.toLevel?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 26 January 2014 19:55, Ralph Goers <ralph.go...@dslextreme.com>
>>>>>>>>>> wrote:
>>>>>>>>>> I think I must be misunderstanding the part about “If those levels
>>>>>>>>>> were added…”. I don’t understand how a level can be added to a
>>>>>>>>>> class from the config such that it is usable by a programmer at
>>>>>>>>>> compile time.
>>>>>>>>>>
>>>>>>>>>> Ralph
>>>>>>>>>>
>>>>>>>>>>> On Jan 26, 2014, at 5:24 PM, Scott Deboy <scott.de...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Couldn't we no-op instead of throw if the same identical level were
>>>>>>>>>>> registered?
>>>>>>>>>>>
>>>>>>>>>>> If those levels were then added to the same custom level class from
>>>>>>>>>>> the config, could we use that single class in the logger calls?
>>>>>>>>>>>> On Jan 26, 2014 5:15 PM, "Ralph Goers"
>>>>>>>>>>>> <ralph.go...@dslextreme.com> wrote:
>>>>>>>>>>>> I am certain I could create a LevelPlugin that would allow you to
>>>>>>>>>>>> define one or more Levels in the configuration, but to use that
>>>>>>>>>>>> Level the user would have to code:
>>>>>>>>>>>>
>>>>>>>>>>>> logger.log(Level.toLevel(“DIAG”), “hello world”);
>>>>>>>>>>>>
>>>>>>>>>>>> In order to directly reference the level it has to be declared as
>>>>>>>>>>>> a static from somewhere and it can only be instantiated a single
>>>>>>>>>>>> time, so creating it from the configuration will prevent that.
>>>>>>>>>>>>
>>>>>>>>>>>> Ralph
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jan 26, 2014, at 4:03 PM, Scott Deboy <scott.de...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have one goal: to remove my request for new built in levels by
>>>>>>>>>>>>> allowing the levels to be defined strictly via configuration. I
>>>>>>>>>>>>> agree there may be some hurdles but that's my goal.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to avoid the requirement that users provide their own
>>>>>>>>>>>>> level implementation or use a different API.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Scott
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Paul
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boa...@gmail.com>
>>>>
>>>
>>
>
