[
https://issues.apache.org/jira/browse/LOG4J2-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142933#comment-14142933
]
Remko Popma commented on LOG4J2-506:
I am more and more leaning towards using java.io.
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 wrote:
> 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.
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
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
log4j-w
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 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, Ralph Goe
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 t
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, Remko
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, [email protected] wrote:
>
> Doc update regarding how servlet contexts can be nam
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: Log4j
[
https://issues.apache.org/jira/browse/LOG4J2-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142541#comment-14142541
]
Matt Sicker commented on LOG4J2-795:
So what happens if you have log4j-api and log4j-c
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 wrote:
> I have to disagree. The fact that it doesn’t allow and also
> doesn’t allow is a showstopper as far as I am concerned. I
> alway
I have to disagree. The fact that it doesn’t allow and also doesn’t
allow 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 3:49 AM, G
[
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
>
[
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-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14142508#comment-14142508
]
Matt Sicker commented on LOG4J2-506:
Due to the contract differences, I think it'd mak
[
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
>
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
I know, JavaScript!
On 14 September 2014 14:17, Gary Gregory 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 (GMT-05:00)
> To:
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 wrote:
> Bah, at
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
Original message From: Remko Popma
Date:09/20/2014 21:56 (GMT-05:00)
To: Log4J Developers List
Subject
[
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)
>
[
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
>
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 migrat
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 o
Nah, we should just fix our comments...
Gary
Original message From: Remko Popma
Date:09/20/2014 23:11 (GMT-05:00)
To: Developers List Log4J
Subject: Javadoc with v8 doclet
Matt has mentioned a few times that he wanted to use the Javadoc format
produced by java 8, but the
[
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 06215dcad2b00eff3f31fd1f4ce
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
27 matches
Mail list logo
