Re: Best practises for manipulating the JUL Logger in a Plugin
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 lennart.jore...@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: l...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@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
On Feb 2, 2015, at 6:44 PM, Lennart Jörelid lennart.jore...@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.jore...@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: l...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Best practises for manipulating the JUL Logger in a Plugin
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 lennart.jore...@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.jore...@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: l...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+
Thanks,
Jason
Re: Best practises for manipulating the JUL Logger in a Plugin
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 lennart.jore...@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 lennart.jore...@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.jore...@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: l...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
--
+==+
| Bästa hälsningar,
| [sw. Best regards]
|
| Lennart Jörelid
| EAI Architect Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
|
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: l...@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
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.jore...@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: l...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [mojo-dev] Best practises for manipulating the JUL Logger in a Plugin
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 lennart.jore...@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: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype):jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==+
