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>
>
