In any event, I'd like to thank the entire Log4J Developer community here
for hearing out my interface idea without biting my head off -- after all,
it's a "big" change near a GA release :-) It was also nice knowing there
exists a place where a serious technical debate can remain cordial. Kudos.
And I am glad the feature will enhance the product.
On Sat, Jan 25, 2014 at 6: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
>>
>>
>>
--
Cheers,
Paul
