I haven’t had a chance to review your changes. I believe I will be able to do that tonight (Pacific time). I appreciate that you did it as RTC instead of committing it directly in this case.
Ralph On Jul 15, 2014, at 7:03 AM, Bruce Brouwer <bruce.brou...@gmail.com> wrote: > My changes are ready to put in now. Is it equally acceptable to put them in > right now since in your view they are not significant to the api and are more > like a bug fix? > > On Jul 15, 2014 9:39 AM, "Remko Popma" <remko.po...@gmail.com> wrote: > Bruce, with the latest adjustments, your change, even though it is in the API > module, will not break any user code. So IMO this is not a showstopper. > Similarly for Gary's change: this is in the core module, so by definition all > internal and not "public", as is documented on the API manual page. Neither > of these are showstoppers and both of these can go in a 2.0.1 or 2.1 release > without any problem. > > We are just making excuses. If we postpone this release then I'm sure > somebody will come up with a reason why we would need an rc4 etc... > > > On Tue, Jul 15, 2014 at 9:53 PM, Bruce Brouwer <bruce.brou...@gmail.com> > wrote: > I can see that, Ralph. I too want to get 2.0 out the door and I believe we > are really close. There are a couple of small API things, like what Gary > points out and my issue that cause me to desire an rc3. I am totally on board > with rc3 being a very short lived rc (as in a week or two). It would be my > preference for rc3 and 2.0 to be the same thing, or maybe only different in > very minor ways. > > To do this, would it make sense to make a 2.0 branch so we can continue to > work on trunk and then only pull issues from trunk to the branch during this > 1 or 2 week period I mention if it is absolutely necessary? (possibly not > even minor bug fixes) It would help my confidence as a user of log4j2 if I > could use rc3 in some apps during that time. Then cut the 2.0 release from > that branch. > > So as of this moment, my vote is 0 for 2.0, but I believe that very soon my > vote will be +1. > > > On Tue, Jul 15, 2014 at 7:33 AM, Ralph Goers <rgo...@apache.org> wrote: > I think we have been making our first impression - we are afraid to ever say > it is good enough and always want the freedom to break compatibility, so > don't use our code. > > Sent from my iPad > > On Jul 15, 2014, at 4:27 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > >> On Tue, Jul 15, 2014 at 6:47 AM, Remko Popma <remko.po...@gmail.com> wrote: >> About the proposed change for LOG4J2-703/713: I don't see any reason why >> this fix can't go in a 2.0.1 or 2.1 release. >> >> In general, I think we agree that in any release log4j-core can have changes >> that are not binary compatible with previous releases. That is why the api >> and core modules are separate: so we are free to make changes to core... >> >> To be honest, LOG4J2-703/713 doesn't look like a showstopper, or am I >> missing something? >> >> My concerns are twofold: >> >> - The Closer API has changed. The is a 'public' API and breaks BC; whether >> or not we consider this class as public for the purpose of defining our >> semantic versifying is a topic we need to address and document to set >> expectations for our users. If we say 'classes in package foo' should not be >> used by non-log4j-modules, then we are drawn a line in the sand. The fact >> that we do not put these classes in an 'internal' package a la Eclipse is a >> different topic also. >> - First impressions. It would be nice to address easy bugs before 2.0 goes >> out; this seems to be an easy bug. Yes, it could be in 2.0.1 or 2.1 but you >> only make a first impression once. >> >> Gary >> >> >> Sent from my iPhone >> >> On 2014/07/15, at 19:20, Gary Gregory <garydgreg...@gmail.com> wrote: >> >>> Note that while 703 is marked as resolved, the user is still having the >>> problem, so I will re-open it, and I would say another RC is needed to >>> remove 703 from the generated JIRA report/release notes. >>> >>> In the meantime, I will attempt another round-trip of fix/test with the >>> user. >>> >>> Gary >>> >>> >>> On Mon, Jul 14, 2014 at 11:34 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> Since 703 is resolved, I created >>> https://issues.apache.org/jira/browse/LOG4J2-713 and committed a fix to >>> trunk. >>> >>> I wonder what else will pop up on Android. It looks like one of our JDBC >>> classes also depends on JNDI so that would bomb too. >>> >>> Perhaps we should delay voting on 2.0 until we know how 703 and 713 play >>> out. Especially since splitting classes in two might be the only solution. >>> >>> Gary >>> >>> >>> >>> >>> On Mon, Jul 14, 2014 at 11:20 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> I have a simple fix for https://issues.apache.org/jira/browse/LOG4J2-703 >>> "Could not find class 'javax.naming.InitialContext', referenced from method >>> org.apache.logging.log4j.core.lookup.JndiLookup.lookup". >>> >>> This breaks BC in org.apache.logging.log4j.core.util.Closer. >>> >>> So the question is: Are we, and if yes, what modules, allowing ourselves to >>> break BC in a non-major release. >>> >>> Gary >>> >>> >>> On Sat, Jul 12, 2014 at 8:25 PM, Ralph Goers <ralph.go...@dslextreme.com> >>> wrote: >>> This is a vote to release Log4j 2.0, the first GA release of Log4j 2. >>> >>> Please test and cast your votes. >>> [] +1, release the artifacts >>> [] -1, don't release because… >>> >>> The vote will remain open for 72 hours (or more if required). >>> >>> New features: >>> o LOG4J2-519: Added support for generating custom logger wrappers that >>> replace the existing log levels >>> and extended logger wrappers that add custom log levels to the >>> existing ones. >>> o LOG4J2-696: RegexFilter does not match multiline log messages. >>> >>> Fixed Bugs: >>> o LOG4J2-705: Fixed issue where Async Logger does not log thread context >>> stack data. >>> API change: added method getImmutableStackOrNull() to >>> ThreadContext.ContextStack interface. >>> o LOG4J2-631: Update docs to clarify how to use formatter logger and >>> standard logger together. >>> o LOG4J2-441: LoggerConfigs with no Level now inherit the Level from their >>> parent. >>> o LOG4J2-703: Android: Could not find class 'javax.naming.InitialContext', >>> referenced from method >>> org.apache.logging.log4j.core.lookup.JndiLookup.lookup. Thanks to Nelson >>> Melina. >>> o LOG4J2-699: PatternLayout manual page missing documentation on >>> header/footer. >>> o LOG4J2-625: Fixed Serialization error with SocketAppender and Async >>> Loggers. >>> (Fixed in RC2, but wasn't included in release notes.) >>> o LOG4J2-538: JMX GUI: fixed occasional ArrayIndexOutOfBoundsException >>> after pressing "reconfigure with XML below". >>> (Fixed in RC2, but wasn't included in release notes.) >>> o LOG4J2-666: AsyncLoggerContextSelector should ensure that different >>> AsyncLoggerContext objects created by web app classloaders have unique >>> names. >>> o LOG4J2-683: Fix annotation processor warnings on JDK 1.7+. Thanks to >>> Jurriaan Mous. >>> o LOG4J2-694: Fix strange compilation error that popped up in a test >>> class. >>> o LOG4J2-692: Update documentation to specify only Maven 3 is supported. >>> o LOG4J2-690: Log4j Web test dependencies should be in scope "test" in the >>> pom. Thanks to Philip Helger. >>> o LOG4J2-682: Special characters (tab and so on) in PatternLayout do not >>> work. Thanks to Scott Harrington. >>> o LOG4J2-686: Core's OptionConverter support for \b is broken (affects >>> PatternLayout). >>> o LOG4J2-687: Rename >>> org.apache.logging.log4j.core.util.Closer.closeSilent() to closeSilently(). >>> o LOG4J2-688: Make org.apache.logging.log4j.core.layout.PatternLayout >>> immutable. >>> o LOG4J2-707: Some exceptions are not logged when configuration problems >>> are detected. >>> >>> Changes: >>> o LOG4J2-685: Make org.apache.logging.log4j.core.layout.AbstractLayout >>> immutable. >>> o LOG4J2-689: Update Jackson to 2.4.1. >>> o LOG4J2-709: Update Apache Commons Logging to 1.2 from 1.1.3. >>> >>> Tag: https://svn.apache.org/repos/asf/logging/log4j/log4j2/tags/log4j-2.0/ >>> >>> SVN revision: 1610084 >>> >>> Web Site: http://people.apache.org/~rgoers/log4j2/ >>> >>> Artifacts: >>> https://repository.apache.org/content/repositories/orgapachelogging-1004/ >>> >>> You may download all the artifacts by doing: >>> >>> wget -e robots=off --cut-dirs=3 -r -p -np --no-check-certificate >>> https://repository.apache.org/content/repositories/orgapachelogging-1004/org/apache/logging/log4j/ >>> >>> Nexus did not send an email. The list of artifacts can be found at the link >>> above. >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > > > -- > > > Bruce Brouwer > about.me/bruce.brouwer > > >
