[
https://issues.apache.org/jira/browse/LOG4J2-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982432#comment-15982432
]
Izek Greenfield edited comment on LOG4J2-1866 at 4/25/17 6:22 AM:
-
[
https://issues.apache.org/jira/browse/LOG4J2-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Izek Greenfield updated LOG4J2-1866:
Attachment: Add_documentation_.patch
documentation patch file
> Add default value to MdcPa
Github user garydgregory commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
Good to know! Thank you. I wonder if we should then create this under a
"lucene5" package so that we can have a "lucene6" package in a different module
if needed.
---
If your project is
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982395#comment-15982395
]
Matt Sicker commented on LOG4NET-563:
-
Looks nice! I wonder if we should try to event
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved LOG4NET-563.
Resolution: Fixed
I've published the changed pages.
> Site: make the site look like the si
Github user liyuj commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
Lucene 6 and later versions require Java 8 or later.
---
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
[
https://issues.apache.org/jira/browse/LOG4J2-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981932#comment-15981932
]
Gary Gregory commented on LOG4J2-1866:
--
Hi Izek,
Thank you for the patch!
Would yo
Occupational hazard ;-)
On Mon, Apr 24, 2017 at 2:12 PM, Matt Sicker wrote:
> Tearing apart pull requests is what I get paid for at my day job half the
> time. ;)
>
> On 24 April 2017 at 15:59, Gary Gregory wrote:
>
> > Nice batch of comments, Matt.
> >
> > Gary
> > -- Forwarded message
Tearing apart pull requests is what I get paid for at my day job half the
time. ;)
On 24 April 2017 at 15:59, Gary Gregory wrote:
> Nice batch of comments, Matt.
>
> Gary
> -- Forwarded message --
> From: Matt Sicker
> Date: Mon, Apr 24, 2017 at 1:14 PM
> Subject: Re: [apache/lo
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113046338
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113046801
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113046710
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113046093
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113045904
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Nice batch of comments, Matt.
Gary
-- Forwarded message --
From: Matt Sicker
Date: Mon, Apr 24, 2017 at 1:14 PM
Subject: Re: [apache/logging-log4j2] Add a new LuceneAppender which writes
logging events to a lucene index library. (#74)
To: apache/logging-log4j2
Cc: Gary Gregory ,
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981863#comment-15981863
]
Dominik Psenner commented on LOG4NET-563:
-
Awesome! To me it looks ready for publ
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113046499
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113045520
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113044694
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113045083
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user jvz commented on a diff in the pull request:
https://github.com/apache/logging-log4j2/pull/74#discussion_r113044838
--- Diff:
log4j-nosql/src/main/java/org/apache/logging/log4j/nosql/appender/lucene/LuceneAppender.java
---
@@ -0,0 +1,301 @@
+/*
+ * Licensed to
Github user garydgregory commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
Why not use the current version of Lucene? Is the version you are using and
the latest (6.5.0) compatible?
---
If your project is set up for it, you can reply to this email and have your
[
https://issues.apache.org/jira/browse/LOG4J2-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981748#comment-15981748
]
Gary Gregory commented on LOG4J2-1888:
--
Can you post your config file please?
> Log
It'd probably be confusing to make a log4j-core-all that only works with
Java 7 and 8, too, so it'd have to be doable somehow. I wonder how
shaded/shadowed applications are supposed to work in Java 9?
On 24 April 2017 at 14:12, Ralph Goers wrote:
> Yeah, I have no idea how you would build the mo
Yeah, I have no idea how you would build the module-info.class file.
module-info.java is compiled by the compiler and it performs checks to make
sure the things being exported are really there. So you would need to have a
maven module that unpacks all the classes and then compiles the
module-in
[
https://issues.apache.org/jira/browse/LOG4J2-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misagh Moayyed updated LOG4J2-1888:
---
Description:
Running a Java spring boot web application using a "java -jar" type of command
Misagh Moayyed created LOG4J2-1888:
--
Summary: Log4j throws a
java.nio.charset.UnsupportedCharsetException: cp65001
Key: LOG4J2-1888
URL: https://issues.apache.org/jira/browse/LOG4J2-1888
Project: Log
It doesn't sound like there's a proper way to export a Java 9 module from
two separate JARs, though I'm not clear on the details. If we package up
the modules into a sort of log4j-core-all artifact, that'd be an assembly
detail for distribution.
On 24 April 2017 at 13:19, Remko Popma wrote:
> I
I must be missing something, I don't see the problem. Users wouldn't have both
the combined jar and the single-module jars on the classpath together, so there
should not be an issue...
For example, assume our current log4j-core jar is split up into
* log4j-core-slim
* log4j-core-appender-db
*
In theory I agree with this but the devil is in the details.
For example, we want to be able to say that Log4j requires NO third party
dependencies but that we support and take advantage of features provided by
third-party software. This means that even though the third-party jars will now
beco
The general idea I had was that if you include log4j-core in your
dependencies, you'll get log4j-api, log4j-spi, and most of the existing
functionality you already get access to in log4j-core currently. We'd split
out the bits that have extra dependencies for the most part which generally
revolves
Guess what? If I am understanding Stephen correctly uber jars are not going to
work as you can’t have multiple modules that export the same package.
Ralph
> On Apr 24, 2017, at 10:43 AM, Remko Popma wrote:
>
> How many new modules are we talking about, concretely?
>
> Matt mentioned the Stack
How many new modules are we talking about, concretely?
Matt mentioned the StackOverflow questions about transitive dependencies
etc, but I imagine splitting log4j-core into 5 or more new modules will
also cause confusion... It won't be trivial for users to figure out which
of the many modules they
I'd love to see a build simplification here, and CMake has been gathering
momentum for many years now, so it sounds reasonable to me from a high
level at least.
On 24 April 2017 at 07:00, Robert Middleton wrote:
> On Mon, Apr 24, 2017 at 5:20 AM, Thorsten Schöning
> wrote:
> > Guten Tag Robert
I agree with Ralph here. I'm sure we'll figure out rather quickly which
modules are easy to put into rarely updated repositories.
On 24 April 2017 at 11:39, Ralph Goers wrote:
> I would prefer a hybrid approach. First things should be moved to
> separate modules. Then, if they don’t seem to be
I would prefer a hybrid approach. First things should be moved to separate
modules. Then, if they don’t seem to be modified frequently they can be moved
to a separate repo. For example, I think it would be OK for the Flume Appender
to be in a separate repo. It hasn’t changed in quite a while an
On Apr 24, 2017 2:38 AM, "Mikael Ståldal" wrote:
I fully agree with Matt's both proposals.
I'm skeptic to creating more repositories (than we already have) though. I
think that we should start by splitting out modules from log4j-core and
keep those modules in the main repository with synchronize
On Apr 20, 2017 11:43 AM, "Matt Sicker" wrote:
We have it set up as a convenience for PRs, though in theory we could make
Jenkins do it instead. The ASF has a policy of using our own resources for
most things, so I don't think we can even use Travis as our primary CI
anyways.
Apache delivers bi
I guess that log4j-core would include other Log4j implementation stuff also
(that plugins does not need to depend on).
On Mon, Apr 24, 2017 at 4:48 PM, Matt Sicker wrote:
> That would be the goal. Then we can have a log4j-core which has all the
> main plugins (file-related mostly) and other log4
Support Java 9 modules sounds a lot stricter than OSGi modules. Essentially
what is best practices in OSGi is required in JPMS.
Anyways, the ServiceLoader for log4j-api sounds reasonable. The current
solution is basically a custom version of that with additional metadata
(the required API version)
That would be the goal. Then we can have a log4j-core which has all the
main plugins (file-related mostly) and other log4j addons for the 3rd party
dependency ones.
On 24 April 2017 at 09:47, Mikael Ståldal wrote:
> I guess this means that a plugin only needs to depend on log4j-spi (and
> probab
Thanks for all the polishes! This vote ends without enough votes to pass.
I'll make an RC2 when I get a chance.
On 24 April 2017 at 04:24, Mikael Ståldal wrote:
> I have now clean-up the build instructions and added an exclusion for
> README.md so that the RAT check works.
>
> Ready for new rele
I guess this means that a plugin only needs to depend on log4j-spi (and
probably on log4j-api), not on log4j-core or anything else log4j-*.
That would be good.
On Mon, Apr 24, 2017 at 4:44 PM, Matt Sicker wrote:
> Keeping configuration/plugin processing code inside log4j-spi should
> probably b
Keeping configuration/plugin processing code inside log4j-spi should
probably be marked clearly which classes are public APIs and which aren't
then. I'm not sure how many classes would need to be moved around, but that
will require some experimentation to figure out anyways.
On 24 April 2017 at 04
Doing things for Java 9 modules that are beneficial also in Java 7/8 is
good.
Using Java ServiceLoader seems like a good idea, and we should definitely
do it if required to support latest SLF4J.
I am not so sure about refactoring package the structure though. Especially
not if doing so will break
It is and it isn’t. I’ve been working on module support all weekend. There are
a couple of changes that must be made before modules can be effectively
implemented and IMO it is worth doing them whether we support modules or not.
Note that none of these changes require Java 9.
1. Modify the API
Gary, you are missing the point. We are not "going" to java 9. We will be
providing support for it. There was nothing we had to do to support java 8, but
there are changes that must be made, like using StackWalker and being
modularized, for Log4J to be usable by everyone who moves to java 9. If
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981061#comment-15981061
]
Stefan Bodewig commented on LOG4NET-563:
I've reduced the project reports section
On Mon, Apr 24, 2017 at 5:20 AM, Thorsten Schöning
wrote:
> Guten Tag Robert Middleton,
> am Montag, 24. April 2017 um 03:03 schrieben Sie:
>
>> I have tested this on both Linux and Windows. If people are OK with
>> CMake, I can make a PR from this branch.
>
> At least I am, especially looking at
I think that it might be a bit early for us to do too much work for
supporting Java 9 modules.
On Mon, Apr 24, 2017 at 12:03 PM, Mikael Ståldal
wrote:
> This option will only be supported in JDK 9.
> It will be removed in JDK 10.
>
>
> On Sun, Apr 23, 2017 at 6:51 PM, Gary Gregory
> wr
This option will only be supported in JDK 9.
It will be removed in JDK 10.
On Sun, Apr 23, 2017 at 6:51 PM, Gary Gregory
wrote:
> The "big kill switch" straight from the source:
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
>
> --permit-illegal-access
>
> G
The "big kill switch" straight from the source:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html
--permit-illegal-access
Gary
On Apr 23, 2017 9:44 AM, "Matt Sicker" wrote:
> “I have too often seen APIs that seemed like a good idea at the time but
> were, in fact, woeful
I fully agree with Matt's both proposals.
I'm skeptic to creating more repositories (than we already have) though. I
think that we should start by splitting out modules from log4j-core and
keep those modules in the main repository with synchronized versioning and
releases, at least for the 2.9 rel
Perfect. thanks Matt! Hopefully, more PRs in the future :)
thanks,
Chandra
On 24 Apr 2017, 12:59 PM +0530, Matt Sicker , wrote:
> Thanks for the PR! I've gone and remerged it to make sure GitHub was
> updated properly as well.
>
> On 20 April 2017 at 13:47, Chandra wrote:
>
> > Sounds good and
I have now clean-up the build instructions and added an exclusion for
README.md so that the RAT check works.
Ready for new release candidate.
On Sat, Apr 22, 2017 at 6:24 AM, Matt Sicker wrote:
> I'm not sure if the staging part is necessary technically since we're
> slicing up the site artifac
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980921#comment-15980921
]
Dominik Psenner commented on LOG4NET-563:
-
I had just now the time to look throug
Guten Tag Robert Middleton,
am Montag, 24. April 2017 um 03:03 schrieben Sie:
> I have tested this on both Linux and Windows. If people are OK with
> CMake, I can make a PR from this branch.
At least I am, especially looking at the time you invested already and
the results of the former discussi
On Fri, Apr 21, 2017 at 4:35 PM, Robert Middleton wrote:
> On Fri, Apr 21, 2017 at 1:50 PM, Thorsten Schöning
> wrote:
>> Guten Tag Robert Middleton,
>> am Freitag, 21. April 2017 um 18:27 schrieben Sie:
>>
>>> That's correct, there's no need for ant at this point
>>
>> So we are dropping Ant and
In the future, you could always use LowLevelLogUtil for debugging. ;)
On 21 April 2017 at 01:40, wrote:
> LOG4J2-1359 - Remove print statement
>
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/
> commit/31110
Howdy,
While this is all possible, I do not like the idea of jumping from Java 7
to 9. I would rather we go to Java 8 soon and take advantage of the whole
platform cleanly, even if in the case of Instant is a convenience as you
call it. That makes it then less of a difference when we do go to Java
Thanks for the PR! I've gone and remerged it to make sure GitHub was
updated properly as well.
On 20 April 2017 at 13:47, Chandra
wrote:
> Sounds good and I *really* like the auto tagging of PR/s with Jira.
>
> Not sure how ASF works, at least I haven’t been any real contributor to
> any Apache
We have to do something. I am about 3/4 of the way creating java9 modules and I
am not happy with core at all. Far too many classes have to be exported as you
can only name packages, not classes.
I think all the configuration stuff will need to stay in core, which means the
optional dependency
I think I brought this topic up like 3 years ago when I was working on
initial OSGi support, but now that we have 3 more years worth of code
additions and optional features, I think this might be a more appropriate
time to discuss it again in light of experience.
Building log4j-core itself already
63 matches
Mail list logo
