Is there a way to generate code/update the Levels enumeration so a new
Level class isn't required?
Would be great to be able to use logger.detail("Detail message");
Is that what you're thinking of, Remko?
On 1/26/14, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> I haven’t done anything to directly do that. However, custom levels need to
> be mapped to the standard levels in several places. It would be simple to
> add support for that wherever you want it. Level.StdLevel.getStdLevel() is
> the method used to do that.
>
> Ralph
>
> On Jan 26, 2014, at 7:45 AM, Scott Deboy <scott.de...@gmail.com> wrote:
>
>> Are these serialization-wise going to be the same as standard levels?
>>
>> Receivers and apps like Chainsaw would benefit from not requiring the
>> originating level class be included in the classpath.
>>
>> I'm thinking about socketreceiver and to a lesser extent
>> logfilepatternreceiver.
>>
>> Scott
>> On Jan 26, 2014 7:28 AM, "Scott Deboy" <scott.de...@gmail.com> wrote:
>> So I assume we could build on this by adding the ability to generate these
>> custom levels from the config, with no user provided class required?
>>
>>
>>
>> On Jan 26, 2014 12:58 AM, "Ralph Goers" <ralph.go...@dslextreme.com>
>> wrote:
>> >
>> > I have completed the work on custom levels. It uses a variation of
>> > Nick’s “extensible enum” class. The major difference with what he
>> > proposed is that the custom enums must be declared in a class annotated
>> > with @Plugin(name=“xxxx” category=“Level”) for them to be usable during
>> > configuration.
>> >
>> > Are their any objections to me checking this in? I’ll be doing the
>> > commit at around noon Pacific Daylight Time if I don’t hear any.
>> >
>> > Ralph
>> >
>> >
>> >
>> > On Jan 25, 2014, at 7:08 AM, Ralph Goers <ralph.go...@dslextreme.com>
>> > wrote:
>> >
>> >> I am working on the implementation of custom levels now. I should have
>> >> it done today.
>> >>
>> >> Ralph
>> >>
>> >> On Jan 24, 2014, at 7:07 PM, Remko Popma <remko.po...@gmail.com>
>> >> wrote:
>> >>
>> >>> What is the best way to make progress on the custom levels
>> >>> implementation?
>> >>>
>> >>> Do we re-open LOG4J-41 or start a fresh Jira ticket? For
>> >>> implementation ideas, do we attach files to Jira, or create a branch?
>> >>>
>> >>> Remko
>> >>>
>> >>> On Saturday, January 25, 2014, Gary Gregory <garydgreg...@gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> On Fri, Jan 24, 2014 at 11:48 AM, Remko Popma <remko.po...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Gary,
>> >>>>>
>> >>>>> The hard-coded levels were proposed because it seemed that the
>> >>>>> extensible enum idea raised by Nick was not going to be accepted.
>> >>>>> My original position was that Markers could fulfill the requirement
>> >>>>> but Nick and yourself made it clear that this was not satisfactory.
>> >>>>>
>> >>>>> With extensible enums and markers off the table it seemed that the
>> >>>>> hard-coded levels was the only alternative, and discussion ensued
>> >>>>> about what these levels should be called and what strength they
>> >>>>> should have.
>> >>>>>
>> >>>>> During this discussion, several people, including me, repeatedly
>> >>>>> expressed strong reservations about adding pre-defined levels, but
>> >>>>> by this time I think people were thinking there was no alternative.
>> >>>>>
>> >>>>> It looked like we were getting stuck, with half the group moving in
>> >>>>> one direction ("add pre-defined levels!") and the other half wanting
>> >>>>> to move in another direction ("don't add pre-defined levels!"). I
>> >>>>> asked that we re-reviewed our assumptions and try to reach a
>> >>>>> solution that would satisfy all users.
>> >>>>>
>> >>>>> We then decided to explore the option of using extensible enums
>> >>>>> again. This is still ongoing, but I haven't seen anyone arguing
>> >>>>> against this idea since we started this thread.
>> >>>>>
>> >>>>> Hard-coded levels and the extensible enum are different solutions to
>> >>>>> the same problem.
>> >>>>
>> >>>>
>> >>>> Hello All:
>> >>>>
>> >>>> Absolutely not. See my DEFCON example.
>> >>>> Talking about an "extensible enum" is mixing design and
>> >>>> implementation, we are talking about 'custom' and/or 'extensible'
>> >>>> levels.
>> >>>> Custom/Extensible levels can be designed to serve one or all of:
>> >>>>
>> >>>> - Allow inserting custom levels between built-in levels.
>> >>>> - Allow for domain specific levels outside of the concept of built-in
>> >>>> levels, the DEFCON example.
>> >>>> - Should the custom levels themselves be extensible?
>> >>>>
>> >>>> Gary
>> >>>>
>> >>>>>
>> >>>>> The extensible enum solution satisfies all of us who are opposed to
>> >>>>> adding pre-defined levels, while also satisfying the original
>> >>>>> requirement raised by Nick and yourself. Frankly I don't understand
>> >>>>> why you would still want the pre-defined levels.
>> >>>>>
>> >>>>> Remko
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sat, Jan 25, 2014 at 12:53 AM, Gary Gregory
>> >>>>> <garydgreg...@gmail.com> wrote:
>> >>>>>>
>> >>>>>> On Thu, Jan 23, 2014 at 10:45 PM, Remko Popma
>> >>>>>> <remko.po...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>> Gary,
>> >>>>>>>
>> >>>>>>> I think that's a very cool idea!
>> >>>>>>> Much more flexible, powerful and elegant than pre-defined levels
>> >>>>>>> could ever be.
>> >>>>>>
>> >>>>>>
>> >>>>>> As I wrote: "I am discussing custom levels here with the
>> >>>>>> understanding that this is a separate topic from what the built-in
>> >>>>>> levels are."
>> >>>>>>
>> >>>>>> I'm not sure why you want to make the features mutually exclusive.
>> >>>>>> (Some) others agree that these are different features.
>> >>>>>>
>> >>>>>> I see two topics:
>> >>>>>>
>> >>>>>> - What are the default levels for a 21st century logging framework.
>> >>>>>> Do we simply blindly copy Log4j 1? Or do we look at frameworks from
>> >>>>>> different languages and platforms for inspiration?
>> >>>>>> - How (not if, I think we all agree) should we allow for custom
>> >>>>>> levels.
>> >>>>>>
>> >>>>>> Gary
>> >>>>>>
>> >>>>>>> It definitely makes sense to design the extensible enum with this
>> >>>>>>> potential usage in mind.
>> >>>>>>>
>> >>>>>>> Remko
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Friday, January 24, 2014, Gary Gregory <garydgreg...@gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> I am discussing custom levels here with the understanding that
>> >>>>>>>> this is a separate topic from what the built-in levels are. Here
>> >>>>>>>> is how I convinced myself that custom levels are a “good thing”.
>> >>>>>>>>
>> >>>>>>>> No matter which built-in levels exits, I may want custom levels.
>> >>>>>>>> For example, I want my app to use the following levels DEFCON1,
>> >>>>>>>> DEFCON2, DEFCON3, DEFCON4, and DEFCON5. This might be for one
>> >>>>>>>> part of my app or a whole subsystem, no matter, I want to use the
>> >>>>>>>> built-in levels in addition to the DEFCON levels. It is worth
>> >>>>>>>> mentioning that if I want that feature only as a user, I can
>> >>>>>>>> “skin” levels in a layout and assign any label to the built-in
>> >>>>>>>> levels. If I am also a developer, I want to use DEFCON levels in
>> >>>>>>>> the source code.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> At first, my code might look like:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> logger.log(DefconLevels.DEFCON5, “All is quiet”);
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Let’s put aside for now the type of DefconLevels.DEFCON* objects.
>> >>>>>>>> I am a user, and I care about my call sites.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> What I really want of course is to write:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> defconLogger.defcon5(“All is quiet”)
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Therefore, I argue that for any “serious” use of a custom level,
>> >>>>>>>> I will wrap a Logger in a custom logger class providing call-site
>> >>>>>>>> friendly methods like defcon5(String).
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> So now, as a developer, all I care about is DefConLogger. It
>> >>>>>>>> might wrap (or subclass) the Log4J Logger, who knows. The
>> >>>>>>>> implementation of DefConLogger is not important to the developer
>> >>>>>>>> (all I care is that the class has ‘defconN’ method) but it is
>> >>>>>>>> important to the configuration author. This tells me that as a
>> >>>>>>>> developer I do not care how DefConLogger is implemented, with
>> >>>>>>>> custom levels, markers, or elves. However, as configuration
>> >>>>>>>> author, I also want to use DEFCON level just like the built-in
>> >>>>>>>> levels.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> The configuration code co
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> >>>> Java Persistence with Hibernate, Second Edition
>> >>>> JUnit in Action, Second Edition
>> >>>> Spring Batch in Action
>> >>>> Blog: http://garygregory.wordpress.com
>> >>>> Home: http://garygregory.com/
>> >>>> Tweet! http://twitter.com/GaryGregory
>> >>
>> >>
>> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
