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