+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
[
https://issues.apache.org/jira/browse/LOG4J2-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-833.
Resolution: Fixed
Assignee: Remko Popma
Pushed to master in commit
Nah, we should just fix our comments...
Gary
div Original message /divdivFrom: Remko Popma
remko.po...@gmail.com /divdivDate:09/20/2014 23:11 (GMT-05:00)
/divdivTo: Developers List Log4J log4j-dev@logging.apache.org
/divdivSubject: Javadoc with v8 doclet /divdiv
/divMatt has
I was a bit shocked after reading the article.
The requirements are very strict.
If you ask me what would be a better use of my time: fix outstanding jiras
or add new features or make javadoc conform to some standard, I think out
of those three, javadoc would benefit our users least...
(I don't
Bah, at some point, that will be the new normal for everyone.
The best way to deal with this is to agree to build with Java 8 with compiler
settings that generate java 6 byte codes which we already have.
If we all pitch in it won't take long.
Personally I do everything in Java 7 and I am
[
https://issues.apache.org/jira/browse/LOG4J2-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-636:
---
Fix Version/s: 2.1
IOException: Stream Closed RollingRandomAccessFile
[
https://issues.apache.org/jira/browse/LOG4J2-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-807:
---
Fix Version/s: 2.1
Disruptor is null when configuration is reloaded (asyncRoot + monitorInterval)
Here us one:
https://logging.apache.org/log4j/2.x/build.html
Hm... but maybe that is fixed in the repo but it should also be fixed in the
branch and published...
Gary
div Original message /divdivFrom: Remko Popma
remko.po...@gmail.com /divdivDate:09/20/2014 21:56
What I don't get is that the OpenJDK javadocs are still a mix of
never-touched 1.0 docs (which definitely uses the loose format), yet they
still manage to build it without fixing all their docs. There must be a way
to auto-fix everything.
On 21 September 2014 08:10, Gary Gregory
I know, JavaScript!
On 14 September 2014 14:17, Gary Gregory garydgreg...@gmail.com wrote:
Right, it seems confusing and does not send a clear message on how to
author your plugins. Can we pick one way?
Gary
Original message
From: Ralph Goers
Date:09/14/2014 13:35
Matt Sicker created LOG4J2-845:
--
Summary: Add API version 2.1.0 to Log4j providers
Key: LOG4J2-845
URL: https://issues.apache.org/jira/browse/LOG4J2-845
Project: Log4j 2
Issue Type: Task
[
https://issues.apache.org/jira/browse/LOG4J2-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-845.
--
Resolution: Fixed
Add API version 2.1.0 to Log4j providers
[
https://issues.apache.org/jira/browse/LOG4J2-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14142508#comment-14142508
]
Matt Sicker commented on LOG4J2-506:
Due to the contract differences, I think it'd
[
https://issues.apache.org/jira/browse/LOG4J2-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-809.
--
Pushed to master.
Move caller class reflection utils to API
-
[
https://issues.apache.org/jira/browse/LOG4J2-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-815.
--
Manual updated.
Unify the two JMS appenders into a single appender
I have to disagree. The fact that it doesn’t allow br / and also doesn’t
allow br/br is a showstopper as far as I am concerned. I always use
closing tags and am not going to change just because doclint doesn’t allow it.
My vote is to disable doclint and move on.
Ralph
On Sep 21, 2014, at
If we can just build it with the (perfectly valid HTML5) invalid HTML by
disabling something, that would be ideal.
On 21 September 2014 12:35, Ralph Goers ralph.go...@dslextreme.com wrote:
I have to disagree. The fact that it doesn’t allow br / and also
doesn’t allow br/br is a showstopper as
[
https://issues.apache.org/jira/browse/LOG4J2-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14142541#comment-14142541
]
Matt Sicker commented on LOG4J2-795:
So what happens if you have log4j-api and
Matt Sicker created LOG4J2-846:
--
Summary: Combine Log4jWebInitializerImpl into a
LoggerContext/LifeCycle wrapper class
Key: LOG4J2-846
URL: https://issues.apache.org/jira/browse/LOG4J2-846
Project:
The docs say
otherwise, the application will fail to start with an exception.
Is this true? Or should that be ...logging will fail to start with an
exception.
Sent from my iPhone
On 2014/09/22, at 8:09, mattsic...@apache.org wrote:
Doc update regarding how servlet contexts can be named.
Well, the way the code currently is written, it looks like it does indeed
throw an exception which would propagate upward to the
ServletContextListener or ServletContainerListener, so it's still correct.
Perhaps it shouldn't actually do that and just log an error?
On 21 September 2014 18:22,
In other places the log4j policy is that logging config errors or errors during
logging should not impact the application unless the user asked for it (as in
audit logging).
So, logging the error would be consistent with that. On the other hand we
haven't had any complaints...
If this fails
If I understand correctly, the article offers a way to do that.
Sent from my iPhone
On 2014/09/22, at 2:58, Matt Sicker boa...@gmail.com wrote:
If we can just build it with the (perfectly valid HTML5) invalid HTML by
disabling something, that would be ideal.
On 21 September 2014 12:35,
Well, as it is now, if this fails, everything fails (until an exception is
caught or the main method lets it go). I could probably modify this to not
fail like that if it can't initialize and just fall back to the default
configuration and such like we normally do. I'm currently refactoring
I see.
My 2c: we have documented the current behaviour and haven't had any complaints
so there's not much reason to change it. This error, if it happens, happens at
deploy time so the users will very likely notice take action. We could change
this to just log the error, I'd be fine with that
WebLogic and WebSphere come to mind, particularly when trying to use log4j
in the server lib instead of just a war.
On 21 September 2014 19:51, Remko Popma remko.po...@gmail.com wrote:
I see.
My 2c: we have documented the current behaviour and haven't had any
complaints so there's not much
26 matches
Mail list logo
