I second my suggestion!
On 26 January 2014 21:44, Ralph Goers <ralph.go...@dslextreme.com> wrote: > My first gut reaction was confusion over Class.forName(). But then in > thinking about it that name does behave a lot like what Class.forName() > does, except with a Level. So I think I do like it better than the current > name. > > Any other thoughts or opinions? > > Ralph > > > On Jan 26, 2014, at 7:28 PM, Matt Sicker <boa...@gmail.com> 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> > > > -- Matt Sicker <boa...@gmail.com>