Would it be an option to require that the custom level class package is
mentioned in the Configuration packages="..." attribute?


On Sun, Jan 26, 2014 at 9:26 AM, 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
>

Reply via email to