Great! That plus support for defining custom levels from the config (with
no custom class required) would mean we would have found a solution that I
believe resolves everyone's issues.
Scott
On Jan 25, 2014 6:52 PM, "Remko Popma" <remko.po...@gmail.com> wrote:
> I've started to think about how to implement Gary's idea to use these
> custom levels to generate code that would add methods to the Logger
> interface, but I think I'll wait a little to see what form the custom
> levels take.
>
>
> On Sun, Jan 26, 2014 at 11:45 AM, Remko Popma <remko.po...@gmail.com>wrote:
>
>> These are the switches I found:
>> * log4j-1.2-api: org.apache.log4j.Category - just FYI, it looks like this
>> switch is missing the FATAL level... is this a bug?
>> * log4j-api: org.apache.logging.log4j.status.StatusLogger
>> * log4j-core: org.apache.logging.log4j.core.net.Severity
>> * log4j-core: org.apache.logging.log4j.core.pattern.LevelPatternConverter
>> - perhaps just return "level " + level.toString(); ?
>> * log4j-to-slf4j: org.apache.logging.slf4j.SLF4JLogger
>>
>>
>>
>> On Sun, Jan 26, 2014 at 11:41 AM, Ralph Goers <ralph.go...@dslextreme.com
>> > wrote:
>>
>>> I am not sure what you mean by this. I have already succeeded in adding
>>> custom level names to the configuration and making them be valid. I am
>>> just trying to clean it up a bit based on what Nick is suggesting.
>>>
>>> Ralph
>>>
>>> On Jan 25, 2014, at 6:30 PM, Scott Deboy <scott.de...@gmail.com> wrote:
>>>
>>> There's no way to add support for users to define level entries (name
>>> and value pairs as a new element in the config) and have us do the work to
>>> make those valid? That would get get rid of my request for additional
>>> levels, right?
>>> On Jan 25, 2014 6:15 PM, "Ralph Goers" <ralph.go...@dslextreme.com>
>>> wrote:
>>>
>>>> The class is needed because it is a name and a value (two items) that
>>>> has to be represented as a single parameter to Logger methods. Using raw
>>>> int or String is not a good alternative.
>>>>
>>>> Ralph
>>>>
>>>> On Jan 25, 2014, at 4:54 PM, Scott Deboy <scott.de...@gmail.com> wrote:
>>>>
>>>> If levels are just a name and a value why require a class at all? What
>>>> about just having it defined in the configuration.
>>>> On Jan 25, 2014 4:37 PM, "Ralph Goers" <ralph.go...@dslextreme.com>
>>>> wrote:
>>>>
>>>>> Because we don’t know the class name that the Level belongs to. It is
>>>>> referenced in the configuration just as “DIAG”, not
>>>>> “org.apache.logging.test.ExtendedLevel.DIAG”.
>>>>>
>>>>> In any case I fixed it. I just annotated the new Level as a Plugin
>>>>> and then look up all the Level plugins in BaseConfiguration. Simply
>>>>> calling
>>>>> the getEnumConstants method on each of the classes does the trick.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>> On Jan 25, 2014, at 4:26 PM, Paul Benedict <pbened...@apache.org>
>>>>> wrote:
>>>>>
>>>>> If you made it a requirement for the constructor to register, why not
>>>>> just instantiate each level as you encounter it in the config?
>>>>>
>>>>>
>>>>> On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers <
>>>>> ralph.go...@dslextreme.com> wrote:
>>>>>
>>>>>> Hmm. It seems I am going to have to do something to force the
>>>>>> registration as the custom level class hasn’t been constructed before the
>>>>>> levels are referenced in the configuration.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jan 25, 2014, at 3:43 PM, Ralph Goers <ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>> In the constructor each of them calls Levels.addLevel(this).
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>> On Jan 25, 2014, at 2:21 PM, Remko Popma <remko.po...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Interesting! So, users would add custom levels by creating a new enum
>>>>>> that implements the Level interface? How does the new enum get
>>>>>> registered?
>>>>>> In config or in code?
>>>>>>
>>>>>> Just trying to understand how it works...
>>>>>>
>>>>>> (With Nick's class I understood how that would work: users would
>>>>>> extend the Level class and pass an instance of that class to the
>>>>>> Logger.log() methods; in config they could specify the new Level name,
>>>>>> and
>>>>>> the Level.toLevel(String, Level) method would find the custom instance
>>>>>> in a
>>>>>> static HashMap in the Level superclass.)
>>>>>>
>>>>>> On Sunday, January 26, 2014, Ralph Goers <ralph.go...@dslextreme.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Here is what I am implementing:
>>>>>>>
>>>>>>> 1. Level is now an Interface. This allows the vast amount of code
>>>>>>> to continue to work.
>>>>>>> 2. The current Level enum has been renamed to StdLevel. It
>>>>>>> implements the Level interface.
>>>>>>> 3. A new class named Levels is in the spi package of the API. It
>>>>>>> contains a ConcurrentMap containing all the registered Levels as well as
>>>>>>> the static methods that were previously part of the Level enum.
>>>>>>>
>>>>>>> For the most part the conversion to this has been pretty easy. The
>>>>>>> most frustrating part was that I had to move the toLevel methods from
>>>>>>> what
>>>>>>> was the Level enum to the Levels class as static methods are not
>>>>>>> allowed in
>>>>>>> interfaces until Java 8. This meant I had to modify several classes to
>>>>>>> use
>>>>>>> Levels.toLevel instead of Level.toLevel. In addition, a few classes
>>>>>>> were
>>>>>>> using the valueOf enum method. Those were converted to use
>>>>>>> Levels.getLevel.
>>>>>>>
>>>>>>> The few places were Level is actually used as an enum were also
>>>>>>> pretty easy to handle as in those cases the custom levels need to be
>>>>>>> converted to a StdLevel and then that enum is used.
>>>>>>>
>>>>>>> Unless anyone objects I plan on committing this later today once I
>>>>>>> finish it and create some tests and documentation.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jan 25, 2014, at 12:49 PM, Nicholas Williams <
>>>>>>> nicho...@nicholaswilliams.net> wrote:
>>>>>>>
>>>>>>> No, of course, everyone seems to agree that custom levels should be
>>>>>>> permitted. But I never heard agreement on whether we were going the
>>>>>>> extensible enum route or the Level-as-interface route. The camp still
>>>>>>> seemed to disagree on that.
>>>>>>>
>>>>>>> Nick
>>>>>>>
>>>>>>> Sent from my iPhone, so please forgive brief replies and frequent
>>>>>>> typos
>>>>>>>
>>>>>>> On Jan 25, 2014, at 11:20, Ralph Goers <ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I have not heard anyone disagree with allowing custom Levels. The
>>>>>>> disagreement I am hearing is over adding new pre-defined levels.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Jan 25, 2014, at 7:29 AM, Nick Williams <
>>>>>>> nicho...@nicholaswilliams.net> wrote:
>>>>>>>
>>>>>>> I may have missed something. Did we decide on an approach? Last I
>>>>>>> heard, the camp was still split: Some wanted to go with my extensible
>>>>>>> enum,
>>>>>>> others wanted to change Level to an interface and make a Levels enum.
>>>>>>>
>>>>>>> So I'm a bit confused. Which implementation are you working on?
>>>>>>>
>>>>>>> Nick
>>>>>>>
>>>>>>> On Jan 25, 2014, at 7:08 AM, Ralph Goers 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
