Thanks! Between reading the code and your answer, I was able to greatly simplify the code.
Nick 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
