Maybe it's something worth discussing for version 3.0 :-) but you could
have something like this:
public interface LogManager {
<T> T getLogger(Class<T> clz);
}
My suggestion is about allowing a "logger" (in the abstract) to be more
than just the definite Logger interface. Having 200-some methods is a lot!
I recommend to the team to think about splitting this up into many
interfaces.
I don't have any design issue with asking clients to grab different logger
interfaces for specialized purposes.
Food for thought.
Cheers,
Paul
On Tue, Feb 16, 2016 at 10:20 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:
> Well, you just need one interface: FlowLogger and all traceEntry and
> traceExit methods can live there. But that means that a user must hold on
> to 2 loggers for a given class for example. Unless FlowLogger extends
> Logger. Then you'd also need to add getFlowLogger methods to LogManager.
>
> Which is better?
> On Feb 15, 2016 7:58 PM, "Paul Benedict" <pbened...@apache.org> wrote:
>
>> You could create special interfaces for these sets of special methods.
>> There is not a design rule that says Logger must be the interface that does
>> all things.
>> Yep, that's definitely one of the candidates for a solution.
>>
>> Sent from my iPhone
>>
>> On 2016/02/16, at 9:43, Gary Gregory <garydgreg...@gmail.com> wrote:
>>
>> Which is one of the reasons I proposed "level logging". I'm on my phone
>> so I can't do more that say there is a branch and Jira for my proposal. You
>> only add a method once, not once per level. Then you say
>> logger.alevel.log(...).
>>
>> Gary
>> On Feb 15, 2016 3:47 PM, "Remko Popma" <remko.po...@gmail.com> wrote:
>>
>>> A word of caution: the Logger API already has 209 method (and I think a
>>> few just got added). This will explode if we just add "var-arg unrolling"
>>> methods for 1 param, 2 params, 3 params, ... (up to how many?) Especially
>>> if we want to also prevent auto boxing in all possible combinations of the
>>> primitive types boolean, long and double.
>>>
>>> There may be other ways to accomplish this. Let's think about this a bit
>>> longer. I'll add a Jira for this in the no-GC epic.
>>>
>>> Sent from my iPhone
>>>
>>> On 2016/02/16, at 1:59, Matt Sicker <boa...@gmail.com> wrote:
>>>
>>> Considering the garbage-free epic, this sounds like a good idea to bake
>>> in from the start.
>>>
>>> On 15 February 2016 at 10:39, Gary Gregory <garydgreg...@gmail.com>
>>> wrote:
>>>
>>>> Hi All:
>>>>
>>>> My my custom flow logger, I avoid auto-boxing on traceExit() calls by
>>>> having primitive versions of the APIs. We could do the same and avoid
>>>> auto-boxing unless a logger's level is enabled.
>>>>
>>>> This generates a lot less garbage when, for example, we flow trace our
>>>> JDBC APIs and get 50m rows and 50 columns per row.
>>>>
>>>> Thoughts?
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <boa...@gmail.com>
>>>
>>>
