You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Nick Williams <ni...@nicholaswilliams.net> on 2013/03/25 04:54:54 UTC
Log4j 2 Taglib
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/
Re: Log4j 2 Taglib
Posted by Ralph Goers <ra...@dslextreme.com>.
I want to start the process but I am still addressing some issues. I'll make sure to apply the patch if it is clean before the release.
Ralph
On Apr 16, 2013, at 9:04 PM, Nick Williams wrote:
> Thanks for applying the patch adding the tag library. I'm excited about it being included!
>
> I have updated https://issues.apache.org/jira/browse/LOG4J2-187 with two new patches. It would be great to get them applied before you release beta5 (are y'all releasing it tomorrow?).
>
> - log4j-taglib-build-install.patch: updates the "Build & Install" page in the main site to include information about the log4j-taglib Maven artifact.
> - log4j-taglib-tests-fixes.patch: adds 78 unit tests!; fixes a bug; resolves some compiler, FindBugs, and CheckStyle warnings; and resolves a potential ClassLoader (memory) leak. :-)
>
> Let me know if you have any questions.
>
> Nick
>
> On Mar 28, 2013, at 5:56 PM, Ralph Goers wrote:
>
>> OK - I have been absolutely swamped at work for a couple months straight so I can't promise when I will take a look at it. I also want to look at the async patch but I'm not sure I will be able to do that before beta5. If Gary could look at it that would be great.
>>
>> Ralph
>>
>>
>> On Mar 28, 2013, at 2:53 PM, Nick Williams wrote:
>>
>>> Code complete!
>>>
>>> I created an issue and attached a patch for it: https://issues.apache.org/jira/browse/LOG4J2-187
>>>
>>> I will be working on some unit tests next week after the holidays, but my initial manual tests with a small web application show it to be working perfectly. I'd love if someone could go ahead and commit this so that:
>>>
>>> 1) It's available as a -beta5 artifact so that people can go ahead and start hammering on it / providing feedback.
>>> 2) My OCD is satisfied that I don't have so much uncommitted code sitting around.
>>>
>>> As mentioned in an earlier email, my ICLA is on file now so there should be no legal issues remaining.
>>>
>>> Thanks!
>>>
>>> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
Thanks for applying the patch adding the tag library. I'm excited about it being included!
I have updated https://issues.apache.org/jira/browse/LOG4J2-187 with two new patches. It would be great to get them applied before you release beta5 (are y'all releasing it tomorrow?).
- log4j-taglib-build-install.patch: updates the "Build & Install" page in the main site to include information about the log4j-taglib Maven artifact.
- log4j-taglib-tests-fixes.patch: adds 78 unit tests!; fixes a bug; resolves some compiler, FindBugs, and CheckStyle warnings; and resolves a potential ClassLoader (memory) leak. :-)
Let me know if you have any questions.
Nick
On Mar 28, 2013, at 5:56 PM, Ralph Goers wrote:
> OK - I have been absolutely swamped at work for a couple months straight so I can't promise when I will take a look at it. I also want to look at the async patch but I'm not sure I will be able to do that before beta5. If Gary could look at it that would be great.
>
> Ralph
>
>
> On Mar 28, 2013, at 2:53 PM, Nick Williams wrote:
>
>> Code complete!
>>
>> I created an issue and attached a patch for it: https://issues.apache.org/jira/browse/LOG4J2-187
>>
>> I will be working on some unit tests next week after the holidays, but my initial manual tests with a small web application show it to be working perfectly. I'd love if someone could go ahead and commit this so that:
>>
>> 1) It's available as a -beta5 artifact so that people can go ahead and start hammering on it / providing feedback.
>> 2) My OCD is satisfied that I don't have so much uncommitted code sitting around.
>>
>> As mentioned in an earlier email, my ICLA is on file now so there should be no legal issues remaining.
>>
>> Thanks!
>>
>> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>
Re: Log4j 2 Taglib
Posted by Ralph Goers <ra...@dslextreme.com>.
OK - I have been absolutely swamped at work for a couple months straight so I can't promise when I will take a look at it. I also want to look at the async patch but I'm not sure I will be able to do that before beta5. If Gary could look at it that would be great.
Ralph
On Mar 28, 2013, at 2:53 PM, Nick Williams wrote:
> Code complete!
>
> I created an issue and attached a patch for it: https://issues.apache.org/jira/browse/LOG4J2-187
>
> I will be working on some unit tests next week after the holidays, but my initial manual tests with a small web application show it to be working perfectly. I'd love if someone could go ahead and commit this so that:
>
> 1) It's available as a -beta5 artifact so that people can go ahead and start hammering on it / providing feedback.
> 2) My OCD is satisfied that I don't have so much uncommitted code sitting around.
>
> As mentioned in an earlier email, my ICLA is on file now so there should be no legal issues remaining.
>
> Thanks!
>
> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
Code complete!
I created an issue and attached a patch for it: https://issues.apache.org/jira/browse/LOG4J2-187
I will be working on some unit tests next week after the holidays, but my initial manual tests with a small web application show it to be working perfectly. I'd love if someone could go ahead and commit this so that:
1) It's available as a -beta5 artifact so that people can go ahead and start hammering on it / providing feedback.
2) My OCD is satisfied that I don't have so much uncommitted code sitting around.
As mentioned in an earlier email, my ICLA is on file now so there should be no legal issues remaining.
Thanks!
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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Mar 26, 2013, at 9:15 PM, Nick Williams wrote:
> Okay, I'm almost done with this. The only remaining problem I have left to solve is the issue of location information. I have this layout, for testing:
>
> <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} %l - %msg%n"/>
>
> Then I have this in /index.jsp:
>
> <log:error message="Hello, World!" />
>
> When I execute index.jsp, this is what I get:
>
> 21:04:02.222 [http-nio-8080-exec-1] ERROR org.apache.jsp.index_jsp org.apache.logging.log4j.taglib.LoggingMessageTagSupport.doEndTag(LoggingMessageTagSupport.java:104) - Hello, World!
>
> So %logger is right, but %l (location) is not. Obviously I don't expect the location information to be the JSP file (boy that'd be nice), but I DO expect it to be something like org.apache.jsp.index_jsp._jspService(index_jsp.java:xx). I can't seem to find where the location information is being calculated in log4j2 (I used to know this for log4j, but it has been a while).
>
> Can someone provide some insight as to what I need to change where? I'm sure it's just a matter of telling the location information calculator to ignore my new package.
I figured out how to solve this with an AbstractLoggerWrapper. I'll submit an issue and patch tomorrow.
Nick
>
> Nick
>
> On Mar 26, 2013, at 2:25 PM, Gary Gregory wrote:
>
>> On Tue, Mar 26, 2013 at 2:42 PM, Nick Williams <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
Okay, I'm almost done with this. The only remaining problem I have left to solve is the issue of location information. I have this layout, for testing:
<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} %l - %msg%n"/>
Then I have this in /index.jsp:
<log:error message="Hello, World!" />
When I execute index.jsp, this is what I get:
21:04:02.222 [http-nio-8080-exec-1] ERROR org.apache.jsp.index_jsp org.apache.logging.log4j.taglib.LoggingMessageTagSupport.doEndTag(LoggingMessageTagSupport.java:104) - Hello, World!
So %logger is right, but %l (location) is not. Obviously I don't expect the location information to be the JSP file (boy that'd be nice), but I DO expect it to be something like org.apache.jsp.index_jsp._jspService(index_jsp.java:xx). I can't seem to find where the location information is being calculated in log4j2 (I used to know this for log4j, but it has been a while).
Can someone provide some insight as to what I need to change where? I'm sure it's just a matter of telling the location information calculator to ignore my new package.
Nick
On Mar 26, 2013, at 2:25 PM, Gary Gregory wrote:
> On Tue, Mar 26, 2013 at 2:42 PM, Nick Williams <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: Log4j 2 Taglib
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 26, 2013 at 2:42 PM, Nick Williams <
nicholas@nicholaswilliams.net> 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 <
> nicholas@nicholaswilliams.net> 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 <
>> nicholas@nicholaswilliams.net> 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 <
>> garydgregory@gmail.com> wrote:
>> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <
>> nicholas@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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)?
- 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)?
- 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?
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 <ni...@nicholaswilliams.net> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
On Mar 25, 2013, at 9:09 PM, Gary Gregory wrote:
> On Mon, Mar 25, 2013 at 9:24 PM, Nick Williams <ni...@nicholaswilliams.net> 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
I'm bleeding edge :-) (mostly because I'm writing a book). Everything I do now is Java SE 8 and Java EE 7.
Nick
>
>
> 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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: Log4j 2 Taglib
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 25, 2013 at 9:24 PM, Nick Williams <
nicholas@nicholaswilliams.net> 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 <
> nicholas@nicholaswilliams.net> 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 <
> garydgregory@gmail.com> wrote:
> >>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <
> nicholas@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
> >>>>> 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: log4j-dev-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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?
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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>>> 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: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Ralph Goers <rg...@apache.org>.
You are on the right track.
Sent from my iPad
On Mar 25, 2013, at 7:29 AM, Nick Williams <ni...@nicholaswilliams.net> 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 <ga...@gmail.com> wrote:
>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ga...@gmail.com> wrote:
> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <ni...@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Log4j 2 Taglib
Posted by Paul Benedict <pb...@apache.org>.
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 <ga...@gmail.com>wrote:
> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <
> nicholas@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: Log4j 2 Taglib
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams <
nicholas@nicholaswilliams.net> 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: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Log4j 2 Taglib
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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?
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/
>
Re: Log4j 2 Taglib
Posted by Ralph Goers <ra...@dslextreme.com>.
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/