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