I now have an ICLA on file with the ASF Secretary under this email address.
Nick On Mar 26, 2013, at 5:31 PM, Ralph Goers wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
