When I build using `mvn clean install` and `mvn site`, I get hundreds of
warnings like the one below (though the build is successful). Is this normal?
WARNING: Could not intialize the host network interface on nullbecause of an
error: nick.williams: nick.williams: nodename nor servname provided, or not
known
java.net.UnknownHostException: nick.williams: nick.williams: nodename nor
servname provided, or not known
at java.net.InetAddress.getLocalHost(InetAddress.java:1438)
at javax.jmdns.impl.HostInfo.newHostInfo(HostInfo.java:76)
at javax.jmdns.impl.JmDNSImpl.<init>(JmDNSImpl.java:407)
at javax.jmdns.JmDNS.create(JmDNS.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.logging.log4j.core.net.MulticastDNSAdvertiser.createJmDNSVersion3(MulticastDNSAdvertiser.java:137)
at
org.apache.logging.log4j.core.net.MulticastDNSAdvertiser.initializeJMDNS(MulticastDNSAdvertiser.java:223)
at
org.apache.logging.log4j.core.net.MulticastDNSAdvertiser.<clinit>(MulticastDNSAdvertiser.java:35)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:188)
at
org.apache.logging.log4j.core.config.plugins.PluginManager.decode(PluginManager.java:229)
at
org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins(PluginManager.java:150)
at
org.apache.logging.log4j.core.config.plugins.PluginManager.collectPlugins(PluginManager.java:129)
at
org.apache.logging.log4j.core.pattern.PatternParser.<init>(PatternParser.java:115)
at
org.apache.logging.log4j.core.pattern.PatternParser.<init>(PatternParser.java:101)
at
org.apache.logging.log4j.core.layout.PatternLayout.createPatternParser(PatternLayout.java:171)
at
org.apache.logging.log4j.core.layout.PatternLayout.<init>(PatternLayout.java:109)
at
org.apache.logging.log4j.core.layout.PatternLayout.createLayout(PatternLayout.java:201)
at
org.apache.logging.log4j.core.config.DefaultConfiguration.<init>(DefaultConfiguration.java:49)
at
org.apache.logging.log4j.core.LoggerContext.<init>(LoggerContext.java:54)
at
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.locateContext(ClassLoaderContextSelector.java:200)
at
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:99)
at
org.apache.logging.log4j.core.selector.ClassLoaderContextSelector.getContext(ClassLoaderContextSelector.java:66)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:76)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:33)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:151)
at
org.apache.logging.log4j.core.pattern.RootThrowableTest.setupClass(RootThrowableTest.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.UnknownHostException: nick.williams: nodename nor servname
provided, or not known
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:866)
at
java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1258)
at java.net.InetAddress.getLocalHost(InetAddress.java:1434)
... 51 more
On Mar 26, 2013, at 2:25 PM, Gary Gregory wrote:
> On Tue, Mar 26, 2013 at 2:42 PM, Nick Williams
> <[email protected]> wrote:
> Some questions whose answers did not come to me as obvious when I read the
> JavaDoc:
>
> - If I have a variable typed Object whose actual runtime type is Message and
> I call Logger#anyLogMethod(Object), will the same thing happen as if I called
> Logger#equivLogMethod(Message)?
>
> If you call an Object- or String-typed method, like debug(), then a Message
> is created for the Object or String through
> org.apache.logging.log4j.message.MessageFactory.newMessage(Object). A Logger
> can be configured with different kinds of message factories, the default
> being ParameterizedMessageFactory, which uses the "Hello {} from {}" format.
> If you want to use java.util.Formatter formats, like "Hello %s from %s" then
> use a StringFormatterMessageFactory.
>
> Likewise, if I have a variable typed Object whose actual runtime type is
> String and I call Logger#anyLogMethod(Object), will the same thing happen as
> if I called Logger#equivLogMethod(String)?
>
> Yes in the sense that both will cause a new Message to be created through the
> message factory.
>
>
> - Finally, on the Logger methods that accept Throwable arguments, if I call
> one of those methods but the Throwable argument is null, is the result the
> same as if I had called the equivalent method without the Throwable argument?
> Or will it result in an NPE/IAE?
>
> Passing null for a Throwable is a no-op.
>
> Gary
>
>
> This will affect how I implement the base/abstract logging tag class that
> does most of the work. If my assumptions are correct, the code can be pretty
> simple. If they are not, the code will have to decide which method to call,
> which is a LOT of branching logic.
>
> Nick
>
> On Mar 25, 2013, at 9:09 PM, Gary Gregory wrote:
>
>> On Mon, Mar 25, 2013 at 9:24 PM, Nick Williams
>> <[email protected]> wrote:
>> I've put it in groupId org.apache.logging.log4j for now. It will be easy to
>> change the groupId later if needed.
>>
>> Also, my Java package is org.apache.logging.log4j.taglib, in line with other
>> artifacts I've seen within the project. Let me know if this should be
>> different.
>>
>> Finally, a general question. I'm wondering why log4j-web (and, by extension
>> for consistency, log4j-taglib) is compiled against Servlet 2.4 (J2EE 4, and
>> so JSP 2.0)? This seems like maybe not the best choice:
>> - This was released in November 2003 ... almost 10 years ago.
>> - There are no supported versions of Tomcat or GlassFish that don't
>> implement at least Servlet 2.5/Java EE 5.
>> - WebSphere 6.1, the last version to only support J2EE 4, goes end-of-life
>> this coming September.
>> - WebLogic 9 EXTENDED support ends this coming November. Regular support
>> ended 16 months ago. And WebLogic 10 provides no backward-support for J2EE
>> 4. It's Java EE 5 only.
>>
>> Java EE 5 (Servlet 2.5, JSP 2.1) came out 8 years ago (a year after Java 5
>> and a year before Java 6), Java EE 6 (Servlet 3.0, JSP 2.2) 3 1/2 years ago,
>> and Java EE 7 (Servlet 3.1, JSP 2.3) next month. It seems logical and
>> reasonable to me that we wouldn't support anything older than Servlet 2.5
>> (Java EE 5). Also, JSP 2.1 (Java EE 5) has some improvements on the JSP tag
>> library API that would be helpful to have.
>>
>> Therefore, I propose the Servlet dependency for log4j-web and log4j-taglib
>> be Servlet 2.5 (Java EE 5), and that the JSP dependency for log4j-taglib be
>> JSP 2.1 (Java EE 5).
>>
>> Thoughts?
>>
>> +1
>>
>> We could depend on Java 6 or 7 and it would be fine with me. All my work
>> projects are on 6 and home on 6 and 7.
>>
>> Gary
>>
>>
>> Nick
>>
>> On Mar 25, 2013, at 7:13 PM, Ralph Goers wrote:
>>
>> > Yeah, we may want to create another name at the same level as adapters and
>> > move web there too.
>> >
>> > Ralph
>> >
>> > On Mar 25, 2013, at 3:04 PM, Nick Williams wrote:
>> >
>> >> Should this new artifact be a member of groupId org.apache.logging.log4j
>> >> or org.apache.logging.log4j.adapters? log4j-web is in adapters (not sure
>> >> that makes sense, but it is). log4j-tablib isn't really an adapter ...
>> >> it's closer to an extension of the API to support JSP tags. That says to
>> >> me "org.apache.logging.log4j." But it's up to y'all.
>> >>
>> >> Nick
>> >>
>> >> On Mar 25, 2013, at 10:49 AM, Ralph Goers wrote:
>> >>
>> >>> You are on the right track.
>> >>>
>> >>> Sent from my iPad
>> >>>
>> >>> On Mar 25, 2013, at 7:29 AM, Nick Williams
>> >>> <[email protected]> wrote:
>> >>>
>> >>>> I'm a little new to Maven (5-6 months), but I thought I understood
>> >>>> multi-module projects correctly. I could certainly be confused about
>> >>>> something.
>> >>>>
>> >>>> In /log4j/log4j2/trunk/pom.xml, log4j is a multi-module Maven project:
>> >>>>
>> >>>> <modules>
>> >>>> <module>api</module>
>> >>>> <module>core</module>
>> >>>> <module>log4j12-api</module>
>> >>>> <module>slf4j-impl</module>
>> >>>> <module>log4j-to-slf4j</module>
>> >>>> <module>jcl-bridge</module>
>> >>>> <module>flume-ng</module>
>> >>>> <module>web</module>
>> >>>> <module>samples</module>
>> >>>> </modules>
>> >>>>
>> >>>> So by "module" I mean <module>taglib</module> (which, by extension, is
>> >>>> a new artifact under the same groupId org.apache.logging.log4j). I do
>> >>>> not mean a separate project (new groupId), no.
>> >>>>
>> >>>> I definitely agree that it should be a new artifact/module, but I
>> >>>> wanted to make sure nobody had a convincing reason that it should be
>> >>>> part of the log4j-web artifact/module before I started writing.
>> >>>>
>> >>>> Nick
>> >>>>
>> >>>> On Mar 25, 2013, at 9:16 AM, Paul Benedict wrote:
>> >>>>
>> >>>>> If by module you mean a Maven module (another hierarchy of projects),
>> >>>>> then no. But definitely a new Maven artifact.
>> >>>>>
>> >>>>> Paul
>> >>>>>
>> >>>>> On Mon, Mar 25, 2013 at 8:06 AM, Gary Gregory <[email protected]>
>> >>>>> wrote:
>> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams
>> >>>>> <[email protected]> wrote:
>> >>>>> Excellent! I figured as much, regarding SVN and patches. I'll get to
>> >>>>> work on it this week.
>> >>>>>
>> >>>>> One important question before I get started that I think only the
>> >>>>> community should answer: What should its Maven artifact and module
>> >>>>> names be? I'm thinking "log4j-taglib" and "Log4j Tag Library".
>> >>>>>
>> >>>>> Another possible option would be to simply make this part of the
>> >>>>> log4j-web module instead of making it its own module. I could
>> >>>>> certainly understand going that route. On the one hand, fewer modules
>> >>>>> can sometimes be less confusing. On the other hand, for some users
>> >>>>> (like me) they'll need the functionality of the log4j-taglib module
>> >>>>> but not the log4j-web module, or vice versa. I don't necessarily like
>> >>>>> the idea of putting this in log4j-web, but it might be a discussion
>> >>>>> worth having. Thoughts?
>> >>>>>
>> >>>>>
>> >>>>> For me, the fewer modules, the better.
>> >>>>>
>> >>>>> Gary
>> >>>>>
>> >>>>> Well Jakarta Log Taglib and SLF4J Taglib are both under Apache 2.0
>> >>>>> License, so there won't be a problem there. Jakarta is an ASF project
>> >>>>> (and it's retired) so I don't believe I'll need permission there. I'll
>> >>>>> get on the SLF4J dev list and inquire for permission. SLF4J says it's
>> >>>>> based on Jakarta Log Taglib. Don't know if that makes a difference.
>> >>>>>
>> >>>>> Nick
>> >>>>>
>> >>>>> On Mar 24, 2013, at 11:51 PM, Ralph Goers wrote:
>> >>>>>
>> >>>>>> Thanks for the interest! Yes, I think having a tag library would be
>> >>>>>> a great addition. Since we are still using subversion I'm afraid the
>> >>>>>> only way to do this is for you to create a patch and attach it to a
>> >>>>>> Jira. Remko has recently done the same. I'd encourage you to create
>> >>>>>> a separate maven subproject and then you could just attach a zip of
>> >>>>>> it.
>> >>>>>>
>> >>>>>> There are two basic rules at the ASF. 1) All code must be contributed
>> >>>>>> under the Apache License. You cannot copy code that is under an
>> >>>>>> incompatible license. 2) All code contributions must be voluntary -
>> >>>>>> you cannot contribute code that someone else wrote without their
>> >>>>>> permission. As a general rule you can copy code from other ASF
>> >>>>>> projects but you would need to get permission from projects hosted
>> >>>>>> elsewhere.
>> >>>>>>
>> >>>>>> Ralph
>> >>>>>>
>> >>>>>>
>> >>>>>> On Mar 24, 2013, at 8:54 PM, Nick Williams wrote:
>> >>>>>>
>> >>>>>>> First, and introduction, since I'm new to this list:
>> >>>>>>>
>> >>>>>>> My name is Nick Williams, I'm a Software Engineer with UL
>> >>>>>>> (Underwriters' Laboratories) and an active member of the Open Source
>> >>>>>>> community. I've contributed to the Tomcat Project (most recently
>> >>>>>>> quite a bit, I've helped with the WebSockets implementation in
>> >>>>>>> Tomcat [1], though only has a contributor, not a committer) and
>> >>>>>>> worked on various other projects. Currently, I'm working on an
>> >>>>>>> improvement on Spring Security's Session Fixation Protection [2] and
>> >>>>>>> a new FasterXML (Mapping Jackson) module to support JSR310 (Java 8
>> >>>>>>> Date & Time API) data types. I'm also author of the upcoming Wrox
>> >>>>>>> book Professional Java for Web Applications [3, the first public
>> >>>>>>> listing of the book I've seen online yet]. Now, with that said...
>> >>>>>>>
>> >>>>>>> The Jakarta Taglibs project used to have a logging tag library [4],
>> >>>>>>> but that project was retired years ago. SLF4J has a tag library
>> >>>>>>> sub-project [5], but it (obviously) uses the SLF4J API. It would be
>> >>>>>>> nice if the new Log4j 2 project had a tag library available when it
>> >>>>>>> releases (hopefully) later this year.
>> >>>>>>>
>> >>>>>>> The tag library is a very simple module. Eight or nine classes and a
>> >>>>>>> TLD are all that are needed. Jakarta Log Taglib and SLF4J Taglib
>> >>>>>>> (both Apache 2.0) have already done much of the hard work for us. I
>> >>>>>>> would be more than happy to spearhead the development effort to get
>> >>>>>>> this done. So, questions:
>> >>>>>>>
>> >>>>>>> 1) Is there interest in having this Log4j 2 module? I think it would
>> >>>>>>> be a great addition to the project.
>> >>>>>>> 2) What steps do I need to take? I'm used to submitted patches for
>> >>>>>>> Tomcat, but that could be very challenging for an entire module of
>> >>>>>>> the project (as small as that module might be). Still, it's doable.
>> >>>>>>> 3) I see no reason not to re-use viable code in Jakarta/SLF4J. In
>> >>>>>>> all my years working in Open Source, I've never actually
>> >>>>>>> ported/forked code like this. What are the "best practices," so not
>> >>>>>>> as to "steal" or offend?
>> >>>>>>>
>> >>>>>>> Thoughts?
>> >>>>>>>
>> >>>>>>> [1]
>> >>>>>>> http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml
>> >>>>>>> [2] https://jira.springsource.org/browse/SEC-2135
>> >>>>>>> [3] http://109.107.134.101/wbook/bookdet.php?seq=840283
>> >>>>>>> [4] http://jakarta.apache.org/taglibs/log/
>> >>>>>>> [5] http://www.slf4j.org/taglib/
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> E-Mail: [email protected] | [email protected]
>> >>>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> >>>>> Spring Batch in Action: http://bit.ly/bqpbCK
>> >>>>> Blog: http://garygregory.wordpress.com
>> >>>>> Home: http://garygregory.com/
>> >>>>> Tweet! http://twitter.com/GaryGregory
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> 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]
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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]
>>
>>
>>
>>
>> --
>> E-Mail: [email protected] | [email protected]
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> --
> E-Mail: [email protected] | [email protected]
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
