Yes, unfortunately. The unit tests cause lots of exceptions to test error cases and in many cases suppressing the exception messages is difficult.
Ralph On Mar 26, 2013, at 2:36 PM, Nick Williams wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
