You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Lennart Jörelid <le...@gmail.com> on 2015/02/02 16:07:17 UTC

Best practises for manipulating the JUL Logger in a Plugin

Hello all,

I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
encountered a (presumably) common problem. The plugin delegates most of its
work to the JDK-distributed tools XJC and SchemaGen. These two tools use
JUL for logging; and their respective outputs should be emitted onto the
Maven Log for debugging and clarity.

Writing a small Handler which delegates the JUL LogRecords to the active
Maven Log is trivial - but I wonder if I need to reset the JUL root logger
after the tool has been run, or if that is done automagically by Maven.

Basically - will the next downstream plugin which needs to wrap a tool
using JUL be affected by my fiddlings according to the snippet below?

// Redirect the JUL Logging statements to the Maven Log.
final Logger rootLogger = Logger.getLogger("");
rootLogger.setLevel(Level.FINER);
for(Handler current : rootLogger.getHandlers()) {
    rootLogger.removeHandler(current);
}
rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC", getEncoding(false)));

// Fire XJC
if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
XjcLogAdapter(getLog()))) { ... display error message ... }

The approach works as expected - the boldfaced logging statements below are
harvested from the XJC tool being put to work by the jabx2-maven-plugin:

[DEBUG] Created episode directory
[/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
true
[DEBUG] Using explicitly configured encoding [UTF-8]





*[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
createSchemaFactoryFIN: SchemaFactory instance:
com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df[DEBUG]
[XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
allowExternalAccessFIN: Property
"http://javax.xml.XMLConstants/property/accessExternalSchema
<http://javax.xml.XMLConstants/property/accessExternalSchema>" is supported
and has been successfully set by used JAXP implementation.*

-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: Best practises for manipulating the JUL Logger in a Plugin

Posted by Jason van Zyl <ja...@takari.io>.
Since Maven 3.1.0 SLF4J is included with the distribution. The Mojo logger is baked in but you can use SLF4J is you prefer.

On Feb 2, 2015, at 6:58 PM, Lennart Jörelid <le...@gmail.com> wrote:

> From which version of the Maven-Plugin-API are we using SLF4J Loggers,
> Jason?
> In the 2.2.1 plugin API, the AbstractMojo contains an
> org.apache.maven.plugin.logging.Log.
> 
> I presume that this is changed in a later version of the plugin API, right?
> 
> public abstract class AbstractMojo
>    implements Mojo, ContextEnabled
> {
>    /** Instance logger */
>    private Log log;
> 
> 
> 2015-02-03 0:50 GMT+01:00 Jason van Zyl <ja...@takari.io>:
> 
>> 
>> On Feb 2, 2015, at 6:44 PM, Lennart Jörelid <le...@gmail.com>
>> wrote:
>> 
>>> Implying that Maven should simply use SJF4J instead of the Maven
>> logging, I
>>> take it?
>> 
>> Maven does use SLF4J now. We use the slf4j-simple implementation by
>> default. If there are many libraries that use JUL then SLF4J provides a
>> standard funnel for that. It has one for commons-logging as well. I think
>> both of these are small. Not sure if there's any downside to including them
>> if it just helps all these libraries work in Maven.
>> 
>>> And - yes - that would be a simpler approach.
>>> 
>>> (Or at least an approach where one would not need to wrap/convert loggers
>>> to loggers in a custom manner over and over ... ).
>>> 
>>> 2015-02-02 17:02 GMT+01:00 Jason van Zyl <ja...@takari.io>:
>>> 
>>>> Would it be easier if we just packaged jul-over-slf4j in the
>> distribution
>>>> to cover these cases?
>>>> 
>>>> On Feb 2, 2015, at 10:07 AM, Lennart Jörelid <lennart.jorelid@gmail.com
>>> 
>>>> wrote:
>>>> 
>>>>> Hello all,
>>>>> 
>>>>> I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
>>>>> encountered a (presumably) common problem. The plugin delegates most of
>>>> its
>>>>> work to the JDK-distributed tools XJC and SchemaGen. These two tools
>> use
>>>>> JUL for logging; and their respective outputs should be emitted onto
>> the
>>>>> Maven Log for debugging and clarity.
>>>>> 
>>>>> Writing a small Handler which delegates the JUL LogRecords to the
>> active
>>>>> Maven Log is trivial - but I wonder if I need to reset the JUL root
>>>> logger
>>>>> after the tool has been run, or if that is done automagically by Maven.
>>>>> 
>>>>> Basically - will the next downstream plugin which needs to wrap a tool
>>>>> using JUL be affected by my fiddlings according to the snippet below?
>>>>> 
>>>>> // Redirect the JUL Logging statements to the Maven Log.
>>>>> final Logger rootLogger = Logger.getLogger("");
>>>>> rootLogger.setLevel(Level.FINER);
>>>>> for(Handler current : rootLogger.getHandlers()) {
>>>>>  rootLogger.removeHandler(current);
>>>>> }
>>>>> rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC",
>>>> getEncoding(false)));
>>>>> 
>>>>> // Fire XJC
>>>>> if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
>>>>> XjcLogAdapter(getLog()))) { ... display error message ... }
>>>>> 
>>>>> The approach works as expected - the boldfaced logging statements below
>>>> are
>>>>> harvested from the XJC tool being put to work by the
>> jabx2-maven-plugin:
>>>>> 
>>>>> [DEBUG] Created episode directory
>>>>> 
>>>> 
>> [/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
>>>>> true
>>>>> [DEBUG] Using explicitly configured encoding [UTF-8]
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> *[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
>>>> com.sun.xml.bind.v2.util.XmlFactory
>>>>> createSchemaFactoryFIN: SchemaFactory instance:
>>>>> 
>>>> 
>> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
>>>> [DEBUG]
>>>>> [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
>>>>> allowExternalAccessFIN: Property
>>>>> "http://javax.xml.XMLConstants/property/accessExternalSchema
>>>>> <http://javax.xml.XMLConstants/property/accessExternalSchema>" is
>>>> supported
>>>>> and has been successfully set by used JAXP implementation.*
>>>>> 
>>>>> --
>>>>> 
>>>>> --
>>>>> +==============================+
>>>>> | Bästa hälsningar,
>>>>> | [sw. "Best regards"]
>>>>> |
>>>>> | Lennart Jörelid
>>>>> | EAI Architect & Integrator
>>>>> |
>>>>> | jGuru Europe AB
>>>>> | Mölnlycke - Kista
>>>>> |
>>>>> | Email: lj@jguru.se
>>>>> | URL:   www.jguru.se
>>>>> | Phone
>>>>> | (skype):    jgurueurope
>>>>> | (intl):     +46 708 507 603
>>>>> | (domestic): 0708 - 507 603
>>>>> +==============================+
>>>> 
>>>> Thanks,
>>>> 
>>>> Jason
>>>> 
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Takari and Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> http://twitter.com/takari_io
>>>> ---------------------------------------------------------
>>>> 
>>>> In short, man creates for himself a new religion of a rational
>>>> and technical order to justify his work and to be justified in it.
>>>> 
>>>> -- Jacques Ellul, The Technological Society
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> 
>>> --
>>> +==============================+
>>> | Bästa hälsningar,
>>> | [sw. "Best regards"]
>>> |
>>> | Lennart Jörelid
>>> | EAI Architect & Integrator
>>> |
>>> | jGuru Europe AB
>>> | Mölnlycke - Kista
>>> |
>>> | Email: lj@jguru.se
>>> | URL:   www.jguru.se
>>> | Phone
>>> | (skype):    jgurueurope
>>> | (intl):     +46 708 507 603
>>> | (domestic): 0708 - 507 603
>>> +==============================+
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> A man enjoys his work when he understands the whole and when he
>> is responsible for the quality of the whole
>> 
>> -- Christopher Alexander, A Pattern Language
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> -- 
> 
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. 

 -- Paul Graham













---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Best practises for manipulating the JUL Logger in a Plugin

Posted by Lennart Jörelid <le...@gmail.com>.
>From which version of the Maven-Plugin-API are we using SLF4J Loggers,
Jason?
In the 2.2.1 plugin API, the AbstractMojo contains an
org.apache.maven.plugin.logging.Log.

I presume that this is changed in a later version of the plugin API, right?

public abstract class AbstractMojo
    implements Mojo, ContextEnabled
{
    /** Instance logger */
    private Log log;


2015-02-03 0:50 GMT+01:00 Jason van Zyl <ja...@takari.io>:

>
> On Feb 2, 2015, at 6:44 PM, Lennart Jörelid <le...@gmail.com>
> wrote:
>
> > Implying that Maven should simply use SJF4J instead of the Maven
> logging, I
> > take it?
>
> Maven does use SLF4J now. We use the slf4j-simple implementation by
> default. If there are many libraries that use JUL then SLF4J provides a
> standard funnel for that. It has one for commons-logging as well. I think
> both of these are small. Not sure if there's any downside to including them
> if it just helps all these libraries work in Maven.
>
> > And - yes - that would be a simpler approach.
> >
> > (Or at least an approach where one would not need to wrap/convert loggers
> > to loggers in a custom manner over and over ... ).
> >
> > 2015-02-02 17:02 GMT+01:00 Jason van Zyl <ja...@takari.io>:
> >
> >> Would it be easier if we just packaged jul-over-slf4j in the
> distribution
> >> to cover these cases?
> >>
> >> On Feb 2, 2015, at 10:07 AM, Lennart Jörelid <lennart.jorelid@gmail.com
> >
> >> wrote:
> >>
> >>> Hello all,
> >>>
> >>> I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
> >>> encountered a (presumably) common problem. The plugin delegates most of
> >> its
> >>> work to the JDK-distributed tools XJC and SchemaGen. These two tools
> use
> >>> JUL for logging; and their respective outputs should be emitted onto
> the
> >>> Maven Log for debugging and clarity.
> >>>
> >>> Writing a small Handler which delegates the JUL LogRecords to the
> active
> >>> Maven Log is trivial - but I wonder if I need to reset the JUL root
> >> logger
> >>> after the tool has been run, or if that is done automagically by Maven.
> >>>
> >>> Basically - will the next downstream plugin which needs to wrap a tool
> >>> using JUL be affected by my fiddlings according to the snippet below?
> >>>
> >>> // Redirect the JUL Logging statements to the Maven Log.
> >>> final Logger rootLogger = Logger.getLogger("");
> >>> rootLogger.setLevel(Level.FINER);
> >>> for(Handler current : rootLogger.getHandlers()) {
> >>>   rootLogger.removeHandler(current);
> >>> }
> >>> rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC",
> >> getEncoding(false)));
> >>>
> >>> // Fire XJC
> >>> if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
> >>> XjcLogAdapter(getLog()))) { ... display error message ... }
> >>>
> >>> The approach works as expected - the boldfaced logging statements below
> >> are
> >>> harvested from the XJC tool being put to work by the
> jabx2-maven-plugin:
> >>>
> >>> [DEBUG] Created episode directory
> >>>
> >>
> [/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
> >>> true
> >>> [DEBUG] Using explicitly configured encoding [UTF-8]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
> >> com.sun.xml.bind.v2.util.XmlFactory
> >>> createSchemaFactoryFIN: SchemaFactory instance:
> >>>
> >>
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
> >> [DEBUG]
> >>> [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
> >>> allowExternalAccessFIN: Property
> >>> "http://javax.xml.XMLConstants/property/accessExternalSchema
> >>> <http://javax.xml.XMLConstants/property/accessExternalSchema>" is
> >> supported
> >>> and has been successfully set by used JAXP implementation.*
> >>>
> >>> --
> >>>
> >>> --
> >>> +==============================+
> >>> | Bästa hälsningar,
> >>> | [sw. "Best regards"]
> >>> |
> >>> | Lennart Jörelid
> >>> | EAI Architect & Integrator
> >>> |
> >>> | jGuru Europe AB
> >>> | Mölnlycke - Kista
> >>> |
> >>> | Email: lj@jguru.se
> >>> | URL:   www.jguru.se
> >>> | Phone
> >>> | (skype):    jgurueurope
> >>> | (intl):     +46 708 507 603
> >>> | (domestic): 0708 - 507 603
> >>> +==============================+
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Takari and Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> ---------------------------------------------------------
> >>
> >> In short, man creates for himself a new religion of a rational
> >> and technical order to justify his work and to be justified in it.
> >>
> >>  -- Jacques Ellul, The Technological Society
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> >
> > --
> > +==============================+
> > | Bästa hälsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart Jörelid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | Mölnlycke - Kista
> > |
> > | Email: lj@jguru.se
> > | URL:   www.jguru.se
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
>  -- Christopher Alexander, A Pattern Language
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: Best practises for manipulating the JUL Logger in a Plugin

Posted by Jason van Zyl <ja...@takari.io>.
On Feb 2, 2015, at 6:44 PM, Lennart Jörelid <le...@gmail.com> wrote:

> Implying that Maven should simply use SJF4J instead of the Maven logging, I
> take it?

Maven does use SLF4J now. We use the slf4j-simple implementation by default. If there are many libraries that use JUL then SLF4J provides a standard funnel for that. It has one for commons-logging as well. I think both of these are small. Not sure if there's any downside to including them if it just helps all these libraries work in Maven.

> And - yes - that would be a simpler approach.
> 
> (Or at least an approach where one would not need to wrap/convert loggers
> to loggers in a custom manner over and over ... ).
> 
> 2015-02-02 17:02 GMT+01:00 Jason van Zyl <ja...@takari.io>:
> 
>> Would it be easier if we just packaged jul-over-slf4j in the distribution
>> to cover these cases?
>> 
>> On Feb 2, 2015, at 10:07 AM, Lennart Jörelid <le...@gmail.com>
>> wrote:
>> 
>>> Hello all,
>>> 
>>> I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
>>> encountered a (presumably) common problem. The plugin delegates most of
>> its
>>> work to the JDK-distributed tools XJC and SchemaGen. These two tools use
>>> JUL for logging; and their respective outputs should be emitted onto the
>>> Maven Log for debugging and clarity.
>>> 
>>> Writing a small Handler which delegates the JUL LogRecords to the active
>>> Maven Log is trivial - but I wonder if I need to reset the JUL root
>> logger
>>> after the tool has been run, or if that is done automagically by Maven.
>>> 
>>> Basically - will the next downstream plugin which needs to wrap a tool
>>> using JUL be affected by my fiddlings according to the snippet below?
>>> 
>>> // Redirect the JUL Logging statements to the Maven Log.
>>> final Logger rootLogger = Logger.getLogger("");
>>> rootLogger.setLevel(Level.FINER);
>>> for(Handler current : rootLogger.getHandlers()) {
>>>   rootLogger.removeHandler(current);
>>> }
>>> rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC",
>> getEncoding(false)));
>>> 
>>> // Fire XJC
>>> if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
>>> XjcLogAdapter(getLog()))) { ... display error message ... }
>>> 
>>> The approach works as expected - the boldfaced logging statements below
>> are
>>> harvested from the XJC tool being put to work by the jabx2-maven-plugin:
>>> 
>>> [DEBUG] Created episode directory
>>> 
>> [/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
>>> true
>>> [DEBUG] Using explicitly configured encoding [UTF-8]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> *[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
>> com.sun.xml.bind.v2.util.XmlFactory
>>> createSchemaFactoryFIN: SchemaFactory instance:
>>> 
>> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
>> [DEBUG]
>>> [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
>>> allowExternalAccessFIN: Property
>>> "http://javax.xml.XMLConstants/property/accessExternalSchema
>>> <http://javax.xml.XMLConstants/property/accessExternalSchema>" is
>> supported
>>> and has been successfully set by used JAXP implementation.*
>>> 
>>> --
>>> 
>>> --
>>> +==============================+
>>> | Bästa hälsningar,
>>> | [sw. "Best regards"]
>>> |
>>> | Lennart Jörelid
>>> | EAI Architect & Integrator
>>> |
>>> | jGuru Europe AB
>>> | Mölnlycke - Kista
>>> |
>>> | Email: lj@jguru.se
>>> | URL:   www.jguru.se
>>> | Phone
>>> | (skype):    jgurueurope
>>> | (intl):     +46 708 507 603
>>> | (domestic): 0708 - 507 603
>>> +==============================+
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Takari and Apache Maven
>> http://twitter.com/jvanzyl
>> http://twitter.com/takari_io
>> ---------------------------------------------------------
>> 
>> In short, man creates for himself a new religion of a rational
>> and technical order to justify his work and to be justified in it.
>> 
>>  -- Jacques Ellul, The Technological Society
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
> 
> 
> -- 
> 
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language













---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Best practises for manipulating the JUL Logger in a Plugin

Posted by Lennart Jörelid <le...@gmail.com>.
Implying that Maven should simply use SJF4J instead of the Maven logging, I
take it?
And - yes - that would be a simpler approach.

(Or at least an approach where one would not need to wrap/convert loggers
to loggers in a custom manner over and over ... ).

2015-02-02 17:02 GMT+01:00 Jason van Zyl <ja...@takari.io>:

> Would it be easier if we just packaged jul-over-slf4j in the distribution
> to cover these cases?
>
> On Feb 2, 2015, at 10:07 AM, Lennart Jörelid <le...@gmail.com>
> wrote:
>
> > Hello all,
> >
> > I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
> > encountered a (presumably) common problem. The plugin delegates most of
> its
> > work to the JDK-distributed tools XJC and SchemaGen. These two tools use
> > JUL for logging; and their respective outputs should be emitted onto the
> > Maven Log for debugging and clarity.
> >
> > Writing a small Handler which delegates the JUL LogRecords to the active
> > Maven Log is trivial - but I wonder if I need to reset the JUL root
> logger
> > after the tool has been run, or if that is done automagically by Maven.
> >
> > Basically - will the next downstream plugin which needs to wrap a tool
> > using JUL be affected by my fiddlings according to the snippet below?
> >
> > // Redirect the JUL Logging statements to the Maven Log.
> > final Logger rootLogger = Logger.getLogger("");
> > rootLogger.setLevel(Level.FINER);
> > for(Handler current : rootLogger.getHandlers()) {
> >    rootLogger.removeHandler(current);
> > }
> > rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC",
> getEncoding(false)));
> >
> > // Fire XJC
> > if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
> > XjcLogAdapter(getLog()))) { ... display error message ... }
> >
> > The approach works as expected - the boldfaced logging statements below
> are
> > harvested from the XJC tool being put to work by the jabx2-maven-plugin:
> >
> > [DEBUG] Created episode directory
> >
> [/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
> > true
> > [DEBUG] Using explicitly configured encoding [UTF-8]
> >
> >
> >
> >
> >
> > *[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
> com.sun.xml.bind.v2.util.XmlFactory
> > createSchemaFactoryFIN: SchemaFactory instance:
> >
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df
> [DEBUG]
> > [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
> > allowExternalAccessFIN: Property
> > "http://javax.xml.XMLConstants/property/accessExternalSchema
> > <http://javax.xml.XMLConstants/property/accessExternalSchema>" is
> supported
> > and has been successfully set by used JAXP implementation.*
> >
> > --
> >
> > --
> > +==============================+
> > | Bästa hälsningar,
> > | [sw. "Best regards"]
> > |
> > | Lennart Jörelid
> > | EAI Architect & Integrator
> > |
> > | jGuru Europe AB
> > | Mölnlycke - Kista
> > |
> > | Email: lj@jguru.se
> > | URL:   www.jguru.se
> > | Phone
> > | (skype):    jgurueurope
> > | (intl):     +46 708 507 603
> > | (domestic): 0708 - 507 603
> > +==============================+
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
>   -- Jacques Ellul, The Technological Society
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: Best practises for manipulating the JUL Logger in a Plugin

Posted by Jason van Zyl <ja...@takari.io>.
Would it be easier if we just packaged jul-over-slf4j in the distribution to cover these cases?

On Feb 2, 2015, at 10:07 AM, Lennart Jörelid <le...@gmail.com> wrote:

> Hello all,
> 
> I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
> encountered a (presumably) common problem. The plugin delegates most of its
> work to the JDK-distributed tools XJC and SchemaGen. These two tools use
> JUL for logging; and their respective outputs should be emitted onto the
> Maven Log for debugging and clarity.
> 
> Writing a small Handler which delegates the JUL LogRecords to the active
> Maven Log is trivial - but I wonder if I need to reset the JUL root logger
> after the tool has been run, or if that is done automagically by Maven.
> 
> Basically - will the next downstream plugin which needs to wrap a tool
> using JUL be affected by my fiddlings according to the snippet below?
> 
> // Redirect the JUL Logging statements to the Maven Log.
> final Logger rootLogger = Logger.getLogger("");
> rootLogger.setLevel(Level.FINER);
> for(Handler current : rootLogger.getHandlers()) {
>    rootLogger.removeHandler(current);
> }
> rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC", getEncoding(false)));
> 
> // Fire XJC
> if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new
> XjcLogAdapter(getLog()))) { ... display error message ... }
> 
> The approach works as expected - the boldfaced logging statements below are
> harvested from the XJC tool being put to work by the jabx2-maven-plugin:
> 
> [DEBUG] Created episode directory
> [/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
> true
> [DEBUG] Using explicitly configured encoding [UTF-8]
> 
> 
> 
> 
> 
> *[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
> createSchemaFactoryFIN: SchemaFactory instance:
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df[DEBUG]
> [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
> allowExternalAccessFIN: Property
> "http://javax.xml.XMLConstants/property/accessExternalSchema
> <http://javax.xml.XMLConstants/property/accessExternalSchema>" is supported
> and has been successfully set by used JAXP implementation.*
> 
> -- 
> 
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society













---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [mojo-dev] Best practises for manipulating the JUL Logger in a Plugin

Posted by Stephen Connolly <st...@gmail.com>.
Should you really be using the JVM of maven to run these tools?

I would argue no. You should be forking the toolchains specified JVM and
using that forked JVM to do the work. If you do it that way you can
completely control what logging those forked JVMs uses and route it to the
Maven logger of choice

On 2 February 2015 at 15:07, Lennart Jörelid <le...@gmail.com>
wrote:

> Hello all,
>
> I'm in the final phase of revamping the Jaxb2-Maven-Plugin, and have
> encountered a (presumably) common problem. The plugin delegates most of its
> work to the JDK-distributed tools XJC and SchemaGen. These two tools use
> JUL for logging; and their respective outputs should be emitted onto the
> Maven Log for debugging and clarity.
>
> Writing a small Handler which delegates the JUL LogRecords to the active
> Maven Log is trivial - but I wonder if I need to reset the JUL root logger
> after the tool has been run, or if that is done automagically by Maven.
>
> Basically - will the next downstream plugin which needs to wrap a tool
> using JUL be affected by my fiddlings according to the snippet below?
>
> // Redirect the JUL Logging statements to the Maven Log.
> final Logger rootLogger = Logger.getLogger("");
> rootLogger.setLevel(Level.FINER);
> for(Handler current : rootLogger.getHandlers()) {
>     rootLogger.removeHandler(current);
> }
> rootLogger.addHandler(new MavenLogHandler(getLog(), "XJC", getEncoding(false)));
>
> // Fire XJC
> if (XJC_COMPLETED_OK != Driver.run(xjcArguments, new XjcLogAdapter(getLog()))) { ... display error message ... }
>
> The approach works as expected - the boldfaced logging statements below
> are harvested from the XJC tool being put to work by the jabx2-maven-plugin:
>
> [DEBUG] Created episode directory
> [/Users/lj/Development/Projects/Codehaus/github_jaxb2_plugin/target/it/xjc-include-xsds-in-artifact/target/generated-sources/jaxb/META-INF]:
> true
> [DEBUG] Using explicitly configured encoding [UTF-8]
>
>
>
>
>
> *[DEBUG] [XJC]: feb 02, 2015 3:51:53 EM
> com.sun.xml.bind.v2.util.XmlFactory createSchemaFactoryFIN: SchemaFactory
> instance:
> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory@5b6813df[DEBUG]
> [XJC]: feb 02, 2015 3:51:53 EM com.sun.xml.bind.v2.util.XmlFactory
> allowExternalAccessFIN: Property
> "http://javax.xml.XMLConstants/property/accessExternalSchema
> <http://javax.xml.XMLConstants/property/accessExternalSchema>" is supported
> and has been successfully set by used JAXP implementation.*
>
> --
>
> --
> +==============================+
> | Bästa hälsningar,
> | [sw. "Best regards"]
> |
> | Lennart Jörelid
> | EAI Architect & Integrator
> |
> | jGuru Europe AB
> | Mölnlycke - Kista
> |
> | Email: lj@jguru.se
> | URL:   www.jguru.se
> | Phone
> | (skype):    jgurueurope
> | (intl):     +46 708 507 603
> | (domestic): 0708 - 507 603
> +==============================+
>
>