[
https://issues.apache.org/jira/browse/LOG4J2-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16097523#comment-16097523
]
Ajitha edited comment on LOG4J2-1921 at 7/23/17 6:12 AM:
-
We are
[
https://issues.apache.org/jira/browse/LOG4J2-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ajitha updated LOG4J2-1921:
---
Attachment: Log4jExample_using_v2.3.zip
We are working on alternatives. But If you are interested in Android
-1 to throw new RuntimeException(e)
Gary
On Jul 22, 2017 13:48, wrote:
Repository: logging-log4j2
Updated Branches:
refs/heads/LOG4J2-1986 [created] c4814a873
LOG4J2-1986 Public API for parsing the output from
JsonLayout/XmlLayout/YamlLayout
into a LogEvent
Project: http://git-wip-us.apac
Ben Siron created LOG4NET-570:
-
Summary: ILogExtensions don't preserve stack trace of caller
Key: LOG4NET-570
URL: https://issues.apache.org/jira/browse/LOG4NET-570
Project: Log4net
Issue Type: I
I just had a quick look at the files, and I noticed the following potential
problems:
I tried to verify with: gpg --verify apache-log4cxx-0.11.0.tar.gz.asc
apache-log4cxx-0.11.0.tar.gz
but gpg couldn't find the public key - do I need to import a special key at
all?
There's no configure script in
Is this a vote thread or a discussion thread? Was there a vote result?
Ralph
> On Jul 22, 2017, at 12:56 PM, Matt Sicker wrote:
>
> Yup, that's the plan. It doesn't save much in compile/test time on the main
> repo, but it's a nice start, and it also allows us to maintain the Scala
> API on it
[
https://issues.apache.org/jira/browse/LOG4J2-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16097423#comment-16097423
]
Mikael Ståldal commented on LOG4J2-1986:
Work in progress in Git branch LOG4J2-19
Work in progress in Git branch LOG4J2-1986.
On 2017-07-22 22:31, Mikael Ståldal wrote:
Yes, I am putting it in its own Java package.
On 2017-07-22 22:13, Gary Gregory wrote:
Should this API sit in its own package?
On Jul 22, 2017 11:41, "Mikael Ståldal" wrote:
I'll give it a shot:
https:
Yes, I am putting it in its own Java package.
On 2017-07-22 22:13, Gary Gregory wrote:
Should this API sit in its own package?
On Jul 22, 2017 11:41, "Mikael Ståldal" wrote:
I'll give it a shot:
https://issues.apache.org/jira/browse/LOG4J2-1986
On 2017-07-22 20:28, Ralph Goers wrote:
Y
Should this API sit in its own package?
On Jul 22, 2017 11:41, "Mikael Ståldal" wrote:
> I'll give it a shot:
>
> https://issues.apache.org/jira/browse/LOG4J2-1986
>
>
> On 2017-07-22 20:28, Ralph Goers wrote:
>
>> Yes, that is a good idea. Probably XML and YAML as well.
>>
>> Ralph
>>
>> On Jul
Yup, that's the plan. It doesn't save much in compile/test time on the main
repo, but it's a nice start, and it also allows us to maintain the Scala
API on its own which may be useful (e.g., using a Scala-specific build
tool).
On 21 July 2017 at 16:19, Gary Gregory wrote:
> And then, you'll remo
I usually stick to big endian encoding while on the JVM thanks to
ByteBuffer making it easy. If you write your own byte buffer style class,
then it doesn't really matter which endianness you choose as you'll have to
split up larger primitives into bytes regardless.
On 21 July 2017 at 15:10, Gary G
I'll give it a shot:
https://issues.apache.org/jira/browse/LOG4J2-1986
On 2017-07-22 20:28, Ralph Goers wrote:
Yes, that is a good idea. Probably XML and YAML as well.
Ralph
On Jul 22, 2017, at 11:21 AM, Mikael Ståldal wrote:
But here we have a concrete use case: a third-party tool, Lilit
Mikael Ståldal created LOG4J2-1986:
--
Summary: Public API for parsing the output from
JsonLayout/XmlLayout/YamlLayout into a LogEvent
Key: LOG4J2-1986
URL: https://issues.apache.org/jira/browse/LOG4J2-1986
Yes, that is a good idea. Probably XML and YAML as well.
Ralph
> On Jul 22, 2017, at 11:21 AM, Mikael Ståldal wrote:
>
> But here we have a concrete use case: a third-party tool, Lilith, needs to
> parse log events from our JsonLayout. (Our SocketServer in log4j-server have
> the same need, a
But here we have a concrete use case: a third-party tool, Lilith, needs
to parse log events from our JsonLayout. (Our SocketServer in
log4j-server have the same need, and it uses this class.)
Should we provide a public API in log4j-core for doing so, which Lilith,
our SocketServer, and possibl
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j2/pull/97
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
On Sat, Jul 22, 2017 at 6:50 AM, João Paulo Lemes Machado <
lemesmach...@gmail.com> wrote:
> Hi Gary. I sent one list of refactoring opportunities to the dev-mailing
> list. Can you tell me if it was received?
>
Hi,
Feel free to scan the archives to see who got what:
https://logging.apache.org/
Hi All,
Just like anything in log4j-core, we try not break binary compatibility
when we can but we do not bend over backwards like we do for log4j-api.
This class is public probably because Jackson requires it to be, otherwise
I would have made it package private. The fact that we use Jackson for
Yes, we have a JIRA ticket for it:
https://issues.apache.org/jira/browse/LOG4J2-63
On 2017-07-22 18:48, Gary Gregory wrote:
We do for some specific subset. I think we have a JIRA for that. It is in
the 1.2 compact module.
Gary
On Jul 22, 2017 03:50, "Mikael Ståldal" wrote:
Another Apache
We do for some specific subset. I think we have a JIRA for that. It is in
the 1.2 compact module.
Gary
On Jul 22, 2017 03:50, "Mikael Ståldal" wrote:
> Another Apache project, HBase, asks when we will be able to support Log4j
> 1 log4j.properties configuration files.
>
> https://issues.apache.
Gary, what do you say? I think you once added that comment.
On 2017-07-22 16:27, Jörn Huxhorn wrote:
Well… it says
/**
* A Jackson JSON {@link ObjectMapper} initialized for Log4j.
*
* Consider this class private.
*
*/
so I wanted to holler about how to continue.
I’ll give it a sh
[
https://issues.apache.org/jira/browse/LOG4J2-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal updated LOG4J2-1792:
---
Description:
I think that Log4j1ConfigurationConverter does not handle Log4j 1.x property
su
Well… it says
/**
* A Jackson JSON {@link ObjectMapper} initialized for Log4j.
*
* Consider this class private.
*
*/
so I wanted to holler about how to continue.
I’ll give it a shot.
On 22. July 2017 at 15:06:28, Mikael Ståldal (mi...@apache.org) wrote:
> Would it work to use
> org.apac
Hi Gary. I sent one list of refactoring opportunities to the dev-mailing
list. Can you tell me if it was received?
2017-07-20 17:16 GMT-03:00 Gary Gregory (JIRA) :
>
> [ https://issues.apache.org/jira/browse/LOG4J2-1979?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpa
Would it work to use
org.apache.logging.log4j.core.jackson.Log4jJsonObjectMapper, which is
public?
See here how it is used:
https://github.com/apache/logging-log4j-tools/blob/master/log4j-server/src/main/java/org/apache/logging/log4j/server/JsonInputStreamLogEventBridge.java
On 2017-07-22 13
It seems like I don’t get access to the log4j2 ObjectMapper or Jackson Module
used for JSON serialization, i.e. I can’t do something like this:
new JacksonFactory.JSON(encodeThreadContextAsList, includeStacktrace, false)
It would make sense to reuse your ObjectMapper/Module in my code instead of
Another Apache project, HBase, asks when we will be able to support
Log4j 1 log4j.properties configuration files.
https://issues.apache.org/jira/browse/HBASE-10092?focusedCommentId=16097039&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16097039
28 matches
Mail list logo