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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> >>>>>> 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 <[email protected]> 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 <[email protected]> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Paul >>>> >>> >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >> >
