+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
[
https://issues.apache.org/jira/browse/LOG4J2-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-678:
---
Description:
Various minor issues found with the site/documentation during review for RC2
and
[
https://issues.apache.org/jira/browse/LOG4J2-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060052#comment-14060052
]
Remko Popma commented on LOG4J2-704:
I tried but I am unable to reproduce the issue.
C
[
https://issues.apache.org/jira/browse/LOG4J2-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-321:
---
Fix Version/s: (was: 2.0-rc1)
2.1
It is not possible to define a ContextSelect
On Sunday, July 13, 2014, Bruno Mahé wrote:
> Hi,
>
> We have been testing Apache Log4j 2.0rc2 at Tango for a few weeks and have
> been very impressed.
> We are in the process of migrating our services to Apache Log 2.0rc2 so
> they can be ready for roll out when 2.0 comes out.
>
> The only issu
On Sunday, July 13, 2014, Bruce Brouwer wrote:
> Here is what I am thinking. I will make the branch tomorrow and put just
> the minimal changes in place with the modified StatusLogger api. This way
> when I fix things completely we won't have a breaking api change after 2.0
> release. If you like
After the 2.0 release, how are we going to do versioning?
One idea is to have 2.0.x releases with bugfixes only, where new features
and any API changes would go into a 2.1 release.
Another way of doing this is to simply have a 2.1 release next containing
both bugfixes and new features as well as
I think we just work as usual in trunk and release when ready and use semantic
versioning. No need to maintain branches unless absolutely necessary. API
breakage is only for major versions. We need to decide if that is just for the
API module or all modules.
Gary
Original message --
FYI http://semver.org/
Gary
Original message From: Gary Gregory
Date:07/13/2014 09:59 (GMT-05:00)
To: Log4J Developers List
Subject: RE: Versioning/branching after 2.0 release
I think we just work as usual in trunk and release when ready and use
semantic versioning. No
[
https://issues.apache.org/jira/browse/LOG4J2-696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved LOG4J2-696.
-
Resolution: Fixed
Resolving since no additional comments have been offered.
> RegexFilter does
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
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 ar
Rats! It's not so simple as what I wrote.
The crux of the problem is that the various Configuration classes need to
control what shows up on the console from the StatusLogger. The way they've
been doing that is finding the existing listener and reconfiguring it.
There are some problems that will a
I think it's a good idea to keep old release branches for security fixes
and such. Otherwise, mainline trunk development seems to make sense to me.
On 13 July 2014 10:22, Gary Gregory wrote:
> FYI http://semver.org/
>
> Gary
>
>
> Original message
> From: Gary Gregory
> Date:0
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 wrote:
> Just a note for the record and as we know, we fail building with Java 8
> due to Javadoc 8 doclint er
I suggest making an annotation or something to use for all the internal-use
classes that are in log4j-api. It also helps to make internal use APIs all
in separate packages from public APIs. That way you can make it extra
obvious that if the internal API changes, too bad.
On 13 July 2014 13:44, Br
We really should move discussion issues to a separate thread and leave this one
for voting
Sent from my iPad
> On Jul 13, 2014, at 12:08 PM, Matt Sicker wrote:
>
> Java 8's javadoc errors are a huge problem in older code. The generated
> javadocs from programs like wsimport and xjc don't even
We have a tag so a branch can be made at any time. But I don't know of any ASF
project that does "release maintenance" - everybody just does fixes as we have
here and then creates a new release with whatever fixes and enhancements are
there. The only exceptions to this would be security bugs or
I am hoping this will get cleaned up for the 2.0 release, especially if
this affects the log4j-api module. As soon as we publish 2.0, folks will
have a green light to implement their own loggers and solution and get
hard-wired to the API. As a user, I would imagine that anything in
log4j-api would
Gary, the 2.0 release vote is already in progress. I don’t see adding an
annotation or comment marking something as for internal use as a reason to hold
up the release.
No to renaming StatusLogger. It’s name is perfectly clear to me.
Ralph
On Jul 13, 2014, at 1:04 PM, Gary Gregory wrote:
Bruce,
My opinion is that in production in a web container the StatusLogger should
ALWAYS be routed to stdout. The volume of output should normally be small if
you are logging at Error. Second, in the ideal case you should only have a
single log level, regardless of how many web applications t
Also, StatusLogger is final. Anyone who tries to implement a Logger based on
that is going to have a hard time. StatusLogger is also intentionally primitive
- you can’t do much filtering or routing to appenders, etc - so anyone who
tries to use it for something is probably going to wonder why it
Also, I am against renaming StatusLogger as it will result in modifications to
hundreds of files.
Ralph
On Jul 13, 2014, at 1:08 PM, Ralph Goers wrote:
> Gary, the 2.0 release vote is already in progress. I don’t see adding an
> annotation or comment marking something as for internal use as
I agree with Ralph on all counts regarding StatusLogger. Really, anything
that wants to store the StatusLogger output elsewhere is probably using
standard out redirection.
On 13 July 2014 15:34, Ralph Goers wrote:
> Also, I am against renaming StatusLogger as it will result in
> modifications t
I'm so used to git, I forgot that tags were almost equivalent to branches
as it is. No need to overly complicate things, then. Branches are neat
places to put up some code that isn't ready for the trunk, but you still
want it out there for anyone else to do as they wish with it.
On 13 July 2014 1
I looked through the classes, and no other classes reference javax classes.
No real need to guard against Errors in those cases.
On 11 July 2014 13:30, Matt Sicker wrote:
> Do any of the other lookups reference javax classes?
>
>
> On 11 July 2014 11:00, Gary Gregory wrote:
>
>> Well, sure, bu
+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
The main purpose of this class is to keep a ThreadLocal
variable for keeping track of LoggerContexts. Would it make sense to use
InheritableThreadLocal instead? This way the current thread's LoggerContext
is preserved for new threads in a situation such as asynchronous servlets.
--
Matt Sicker
What guarantee do you have that the asynchronous servlet is in a child thread?
ThreadContextMap was originally an InheritableThreadLocal but had to be changed
to a ThreadLocal due to the problems automatic inheritance causes.
Ralph
On Jul 13, 2014, at 2:56 PM, Matt Sicker wrote:
> The main p
Oh - and the main purpose of the ContextAnchor is to reduce the overhead of
finding the current LoggerContext.
Anyone using asynchronous servlets would probably need to copy the
ThreadContextMap as well as the ContextAnchor for the new Thread.
Ralph
On Jul 13, 2014, at 3:12 PM, Ralph Goers w
I'm all for making this more like a simple on/off switch. But the way
things are setup right now, once you turn on the console logging, it can
never be turned off. That is because once it is registered, nothing ever
removes it.
Are we ok with that?
If we are, then I would like to remove all the l
I haven't studied StatusLogger in that much depth, but what you're saying
sounds good. I agree with Ralph that this is for diagnostics and it's better to
keep this simple.
Sent from my iPhone
> On 2014/07/14, at 8:19, Bruce Brouwer wrote:
>
> I'm all for making this more like a simple on/off
If it can't be turned off that doesn't sound right. You should be able to get
to the listener and change its level so that nothing is logged. I guess you
are meaning the listener can't be removed? For some reason I thought it could.
Ralph
> On Jul 13, 2014, at 4:19 PM, Bruce Brouwer wrote:
Should double check better. Should not be a real performance issue
On Jul 13, 2014 7:35 PM, "Remko Popma" wrote:
> I haven't studied StatusLogger in that much depth, but what you're saying
> sounds good. I agree with Ralph that this is for diagnostics and it's
> better to keep this simple.
>
> Se
The listener can be removed, but nothing ever does. Right now it can never
know if it should be removed. And also, all that level checking is cached
in StatusLogger. If all you do is change the status level of the listener
it has no effect on the cached value in StatusLogger. It may end up having
n
I'm just looking for a way to make this easier to use in async servlets.
I've been implementing some at work lately as an experimental way of
creating a REST facade for a JMS-based service, and having an easier method
to obtaining the right Logger would be nice.
On 13 July 2014 17:16, Ralph Goers
This actually makes me wonder why you can configure the status logger from
a configuration file. Shouldn't this just be a system property or something?
On 13 July 2014 18:57, Bruce Brouwer wrote:
> The listener can be removed, but nothing ever does. Right now it can never
> know if it should be
Matt Sicker created LOG4J2-711:
--
Summary: Add native support for using Log4j in Jetty
Key: LOG4J2-711
URL: https://issues.apache.org/jira/browse/LOG4J2-711
Project: Log4j 2
Issue Type: New Featu
[
https://issues.apache.org/jira/browse/LOG4J2-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060262#comment-14060262
]
Matt Sicker commented on LOG4J2-711:
Or would this be more appropriate to request at J
Ok, this is starting to be simpler, as I'm sure you would all prefer. You
can look at the branch LOG4J-609 again if you like. Here are the
simplifications that I have made.
1) The listeners no longer report their level. They can decide if they want
to do something with a status message in their lo
I'm not sure which approach to follow, so I thought I'd ask out here.
LogManager allows use of ClassLoader arguments. However, using a more
abstracted interface like the ResourceLoader class in log4j-core is more
extensible. In OSGi, you get the same public methods from ClassLoader in
the Bundle in
Ok, the only test that didn't pass was the one testing for StatusLogger
writing to a file. I removed that test on the branch. If you review that
and think it worthy to go into the trunk, I'm pretty much on board with a
2.0 release (unless you think a short lived rc3 is in order).
On Sun, Jul 13,
I'd be ok with another RC. My ideal scenario is that an RC is released, some
time goes by without new bug reports and then the next RC becomes a release. As
things are now, we've fixed plenty since rc2. But hey that's just me ;-)
Gary
Original message From: Bruce Brouwer
Date
[
https://issues.apache.org/jira/browse/LOG4J2-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060297#comment-14060297
]
Sean Bridges commented on LOG4J2-702:
-
Sorry, I commented without seeing some of the p
I guess that means you won't be voting on the current release candidate? Pretty
much everyone else thinks it is time. If that is the case one of the other PMC
members will need to fail or the release vote will fail.
For what it is worth, I have no problem with a 2.0.1 or 2.1 in a few weeks if
d
I, too, would prefer to release now and follow up with updates in the short
term.
On 13 July 2014 23:35, Ralph Goers wrote:
> I guess that means you won't be voting on the current release candidate?
> Pretty much everyone else thinks it is time. If that is the case one of the
> other PMC member
45 matches
Mail list logo
