That was what I was originally thinking. I suspect that what the result of what
we are thinking would be to just be able to dynamically generate the wrapper
based on the custom Level(s).
Ralph
On Jan 25, 2014, at 8:43 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> My idea was _not_ to add byte codes to the Logger interface, it was to add
> code to a user's class that wraps a logger.
>
> G
>
>
> -------- Original message --------
> From: Remko Popma
> Date:01/25/2014 21:51 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Enums and Custom Levels
>
> 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
>>>
>>
>
>
>
