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
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
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
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
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
It's funny, I'm pretty sure I suggested a while back that log4j-core was a
bit fat, and here's just another example of that. Should the database
appenders be split off eventually?
On Monday, 14 July 2014, Gary Gregory garydgreg...@gmail.com wrote:
Since 703 is resolved, I created
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.
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
...@logging.apache.org /divdivSubject: Re:
[VOTE] Log4j 2.0 candidate 1 /divdiv
/divI 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
Fine with me.
Gary
div Original message /divdivFrom: Bruce Brouwer
bruce.brou...@gmail.com /divdivDate:07/15/2014 10:03 (GMT-05:00)
/divdivTo: Log4J Developers List log4j-dev@logging.apache.org
/divdivSubject: Re: [VOTE] Log4j 2.0 candidate 1 /divdiv
/divMy changes are ready
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
I am +1 for the GA release.
First off, I am sorry for being silent that long time and then coming
back with an opinion in this topic as I am just a prime time
contributor. I have to deal with some personal issues which made my days
long and nights short, so I haven't got the time I want to
Here is my +1 vote on the release. I will close the vote in about 8 hours if
anyone else wants to weigh in.
Ralph
On Jul 12, 2014, at 5: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
How do we propose to deal with the fact that the changes.xml documents 703
as fixed when it is not? Leave it as a known bug in 2.0 or fix it and roll
another RC?
Gary
On Tue, Jul 15, 2014 at 6:20 AM, Gary Gregory garydgreg...@gmail.com
wrote:
Note that while 703 is marked as resolved, the
I'll defer to the RM but if the issue itself is not a showstopper then I don't
see how the paperwork for that issue could be a showstopper.
We can update the Jira ticket to note that the full fix isn't in 2.0 and add
another entry for 703 in the 2.0.1 or 2.1 release notes, saying that it is
+1 from me if that means anything.
On 15 July 2014 18:42, Remko Popma rem...@yahoo.com.invalid wrote:
I'll defer to the RM but if the issue itself is not a showstopper then I
don't see how the paperwork for that issue could be a showstopper.
We can update the Jira ticket to note that the
(I did a reply instead of reply-all
Definitely! All votes count, even if not binding. The more people verify the
release, the better.
Sent from my iPhone
On 2014/07/16, at 9:32, Matt Sicker boa...@gmail.com wrote:
+1 from me if that means anything.
On 15 July 2014 18:42, Remko
Sure it's not a showstopper.
+1 with:
Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
2014-06-17T09:51:42-04:00)
Maven home: C:\Java\apache-maven-3.2.2
Java version: 1.7.0_60, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_60\jre
Default locale: en_US,
Can I still get what's on the LOG4J2-609 branch into trunk for this
release? From an API standpoint, the only thing that has changed is that
StatusConsoleListener has moved to log4j-core.
On Tue, Jul 15, 2014 at 10:51 PM, Gary Gregory garydgreg...@gmail.com
wrote:
Sure it's not a showstopper.
For this release, the artifacts have already been created.
I get the impression that things are still in flux with 609. Ralph said he was
going to review, perhaps merge into trunk after that?
I don't see a problem with including your changes or some variation of them in
a subsequent release.
I would be OK with canceling the current VOTE and re-spining from trunk.
I'm not sure if we need a -1 VOTE from someone for that though.
Gary
On Tue, Jul 15, 2014 at 10:57 PM, Bruce Brouwer bruce.brou...@gmail.com
wrote:
Can I still get what's on the LOG4J2-609 branch into trunk for this
The vote is now closed and passes with binding +1 votes from: Remko Popma,
Christian Grobmeier, Ralph Goers and Gary Gregory, although Gary expressed a
desire to have it re-spun as rc3. Additional non-binding +1 votes came from:
Bruno Mahe and Matt Sticker. Bruce Brouwer cast a non-binding
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
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
Just a note for the record and as we know, we fail building with Java 8 due
to Javadoc 8 doclint errors.
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.
Java 8's javadoc errors are a huge problem in older code. The generated
javadocs from programs like wsimport and xjc don't even compile due to this!
On 13 July 2014 12:28, Gary Gregory garydgreg...@gmail.com wrote:
Just a note for the record and as we know, we fail building with Java 8
due to
+1
Artifacts look good, site looks good. Minor site issues:
Checkstyle gives many Disallowed import warnings in these 3 components:
* Implementation: sun.reflect.Reflection, com.fasterxml.jackson.
* Log4j Web Application Support: javax.servlet
* Log4j NoSQL Support: org.lightcouch, com.mongodb and
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
What is the story with the Disallowed import checkstyle warnings?
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,
I have no idea why it is complaining about Jackson. I can understand why it
doesn’t like us using the com.sun stuff. I wonder if we are defaulting to
https://github.com/checkstyle/checkstyle/blob/master/import-control.xml
Ralph
On Jul 12, 2014, at 7:40 PM, Gary Gregory garydgreg...@gmail.com
30 matches
Mail list logo
