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