logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [VOTE] Log4j 2.0 candidate 1
Date Tue, 15 Jul 2014 15:21:35 GMT
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.brouwer@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.popma@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.brouwer@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 <rgoers@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 <garydgregory@gmail.com> wrote:
> 
>> On Tue, Jul 15, 2014 at 6:47 AM, Remko Popma <remko.popma@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 <garydgregory@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 <garydgregory@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 <garydgregory@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.goers@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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
> 
>  
> 


Mime
View raw message