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 follow
closely - hope you understand.
Second, as far as I understood these issues are not blocking enough. For
my understanding the core module might change at almost any time. It's
the core. No guarantees there, we need some freedom to change things
under the hood.
The log4j-api is a different thing. It's what the user sees and relies
on. As long as the interfaces stay compatible - which I understood they
do - I think we are fine to go.
That being said I strongly believe in: release early, often. And I
believe it should be OK even for a logging library to make 2.1, 2.2,
2.3, heck, even a 3.0 version.
Looking at my build here, I can't see anything wrong. Of course I don't
have the in depth knowledge as other devs here.
I don't think problems with JavaDoc or even minor issues should block
this release. To be honest, we would fix for ever to have the one and
perfect version. That said, we have already wait too long to make Log4j
2.0 GA. There was the argument of the first impression - the first
impression more and more becomes that we simply don't have the balls to
make a GA release.
Regards,
Christian
On 15 Jul 2014, at 15:38, Remko Popma 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
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition
<http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
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
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
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
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
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
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
Bruce Brouwer
about.me/bruce.brouwer
[image: Bruce Brouwer on about.me]
<http://about.me/bruce.brouwer>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
