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
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 > >>> <[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
