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