Not that I'd ever ever do this, as the performance would be horrid, but:

In the existing logger impl throw and catch an exception and get the *calling* 
class from the stack back trace.

Utterly horrid but it is doable. But is works with all existing plugins and 
code with out any refactoring (ie backwards compatible).

I also use this technique when in a mess of interface implementations I get 
lost as to whom is calling me. Brute force and ugly, but functional.

-Chris

Sent from my iPhone

On 17/11/2012, at 1:45 AM, Jason van Zyl <[email protected]> wrote:

> 
> On Nov 16, 2012, at 7:30 AM, Benson Margulies <[email protected]> wrote:
> 
>> On Fri, Nov 16, 2012 at 7:03 AM, Chris Graham <[email protected]> wrote:
>>> I prefer classname based, as it is, by definition, definative.
>>> 
>>> If you're concerned about details getting lost, then might I suggest that
>>> you route that logging output to a separate file? trace.log works for me
>>> (and give a -D to allow users to change that as well).
>> 
>> 
>> 
>> Hervé has pointed out that we already have an API that has no natural
>> mapping to a class name. How would you, or Jason, propose to obtain a
>> class name to go with getLog()?
> 
> Inject the SLF4J logger factory and use that with the underlying component 
> descriptor's implementation definition which is the class name. 
> 
>> 
>> 
>> 
>>> 
>>> -Chris
>>> 
>>> 
>>> On Fri, Nov 16, 2012 at 5:39 PM, Hervé BOUTEMY <[email protected]>wrote:
>>> 
>>>> +1 for the idea
>>>> 
>>>> other complementary ideas:
>>>> - groupId is not really useful, plugins's artifactId is in general
>>>> sufficient
>>>> - I'd add goal name
>>>> - dot separator, since this is the classical separator in every java
>>>> logging
>>>> implementations (due to the classical class name as logger pattern)
>>>> - add prefix with something like "maven.", to separate maven logs from logs
>>>> from other tools (probably organized by full class name)
>>>> 
>>>> then my preference would go to
>>>> 
>>>> maven.${artifactId}.${goal}
>>>> 
>>>> which is a "domain specific" pattern, not the classical full class name
>>>> 
>>>> (FYI, that' not the first time I use such "domain specific" logger name
>>>> pattern,
>>>> and I never had problems with such decision: yes, that's a bit not
>>>> conventional but respects logging frameworks and is easy to understand)
>>>> 
>>>> Regards,
>>>> 
>>>> Hervé
>>>> 
>>>> Le jeudi 15 novembre 2012 14:18:46 Olivier Lamy a écrit :
>>>>> Hi,
>>>>> Currently logger for all mojos is the DefaultPluginManager logger.
>>>>> So it's a bit hard to have filtering per plugin (i.e. only compiler in
>>>>> debug etc..)
>>>>> 
>>>>> So I'd like to change that to be able to customize mojo logging.
>>>>> My first is idea is mojo with logger name ${groupId}:${artifactId} (ie
>>>>> org.apache.maven.plugins:maven-clean-plugin) so if you only want debug
>>>>> for compiler put logger org.apache.maven.plugins:maven-compiler-plugin
>>>>> to debug.
>>>>> 
>>>>> Makes sense ?
>>>>> 
>>>>> The code to change is here:
>>>>> 
>>>> https://github.com/olamy/maven-3/blob/log4j2/maven-core/src/main/java/org/ap
>>>>> ache/maven/plugin/internal/DefaultMavenPluginManager.java#L445
>>>>> 
>>>>> WDYT ?
>>>>> 
>>>>> Thanks
>>>>> --
>>>>> Olivier Lamy
>>>>> Talend: http://coders.talend.com
>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
> 
>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
> 
> 
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to