I messed up the code example. Sorry. Let all supported logging interfaces
come from an empty marker interface.
public interface LogManager {
<T extends SomeMarkerInterface> T getLogger(Class<T> clz);
}
Cheers,
Paul
On Tue, Feb 16, 2016 at 10:27 AM, Paul Benedict <pbened...@apache.org>
wrote:
> 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>
>>>>
>>>>
>
