Github user liyuj commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
Lucene5 API and lucene6 are incompatible.
I think the future is divided into multiple modules is more reasonable,
such as log4j-lucene5 and log4j-lucene6.
---
If your project is set up for
Ideally, the two will align, just like the OSGi modules (which tend to
directly correspond with maven modules since that's how they're normally
assembled).
On 25 April 2017 at 13:39, Gary Gregory wrote:
> We are going to have to prefix "module" with "Java" or "Maven" in
> discussions and documen
We are going to have to prefix "module" with "Java" or "Maven" in
discussions and documentation to avoid confusion from now on...
Gary
On Apr 25, 2017 10:59 AM, "Matt Sicker" wrote:
> If you browse around the Java 9 javadocs, you'll see that they split things
> up by module there as well. With
If you browse around the Java 9 javadocs, you'll see that they split things
up by module there as well. With that in mind, hopefully it's not too
complicated to support. What I really want to see is inter-module links
(both Java modules and Maven modules that is) work properly.
On 25 April 2017 at
Ouch. This is where it gets messy. Currently, the javadoc is built
independently for each module. I’m not sure how to aggregate them all together
but I’m sure Java 9 must be doing that with all the modules they are supporting.
Ralph
> On Apr 25, 2017, at 7:03 AM, Mikael Ståldal wrote:
>
> Wh
[
https://issues.apache.org/jira/browse/LOG4PHP-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Kelsey updated LOG4PHP-235:
--
Description:
When attempting to clone the package via composer server certificate
verification
[
https://issues.apache.org/jira/browse/LOG4PHP-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Kelsey updated LOG4PHP-235:
--
Description:
When attempting to clone the package via composer server certificate
verification
Curtis Kelsey created LOG4PHP-235:
-
Summary: Server certificate verification fails via Git
Key: LOG4PHP-235
URL: https://issues.apache.org/jira/browse/LOG4PHP-235
Project: Log4php
Issue Type:
I have started to extract KafkaAppender to its own module, please review
Git branch LOG4J2-1889. This can be a template on how to do it for other
plugins.
On Tue, Apr 25, 2017 at 5:14 PM, Gary Gregory
wrote:
> To be honest here, it feels to me like we are splitting hair. Maybe we
> could proceed
[
https://issues.apache.org/jira/browse/LOG4J2-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983130#comment-15983130
]
ASF subversion and git services commented on LOG4J2-1889:
-
Commit
[
https://issues.apache.org/jira/browse/LOG4J2-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983129#comment-15983129
]
ASF subversion and git services commented on LOG4J2-1889:
-
Commit
To be honest here, it feels to me like we are splitting hair. Maybe we
could proceed with m12n and then do an SPI.
It also feels odd to call it SPI if it has a boatload of "stuff" in it like
our config code.
Maybe we leave -core as in and pull out JRE-based appenders and layouts
into a -basic mod
I'm also thinking that since classes and packages may have to be moved
around a little bit, making plugin refactoring for custom plugins as simple
as possible would be great. A search/replace for package imports should
hopefully be enough.
On 25 April 2017 at 10:03, Matt Sicker wrote:
> No, it w
No, it would define the interfaces (and abstract classes so that we don't
need to introduce Appender2, Appender3, etc., without having default
methods available) along with the core configuration and plugin system.
Essentially all the parts of log4j-core that we want to create a
well-defined servic
Would SPI only contain interfaces?
Gary
On Apr 25, 2017 7:36 AM, "Mikael Ståldal" wrote:
> The goal of log4j-spi is that plugins can depend on log4j-spi (and
> log4j-api), not on log4j-core.
>
> On Tue, Apr 25, 2017 at 4:33 PM, Gary Gregory
> wrote:
>
> > If my app depends on the BOM module, d
Github user jvz commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
That makes sense. In the case of Elasticsearch (1.x, 2.x, and 5.x), you can
support all versions using the same code in certain scenarios (usually simple
things). If Lucene follows the usual Apach
Gary, I don't think you'd want everything from the BOM since it has both
log4j-slf4j-impl and log4j-to-slf4j.
I suppose a more elaborate explanation of log4j-spi is that it would also
need to include the core configuration classes and plugin processing and
whatnot. It wouldn't itself provide any p
The goal of log4j-spi is that plugins can depend on log4j-spi (and
log4j-api), not on log4j-core.
On Tue, Apr 25, 2017 at 4:33 PM, Gary Gregory
wrote:
> If my app depends on the BOM module, do I get everything so I can
> assembly:single them into a zip with my app?
>
> Gary
>
> On Apr 25, 2017 7
Github user garydgregory commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
I was thinking that if you can use Java 8 then you depend on log4j-lucene6
and if you can't then log4j-lucene5.
---
If your project is set up for it, you can reply to this email and have
If my app depends on the BOM module, do I get everything so I can
assembly:single them into a zip with my app?
Gary
On Apr 25, 2017 7:09 AM, "Matt Sicker" wrote:
> I also agree that modules should really stick to required dependencies.
>
> As for only requiring log4j-core, the idea here is that
About log4j-core automatically pulling in api and spi dependencies: bear in
mind that not everyone uses Gradle or Maven... I suspect many enterprise
projects don't.
Does spi need to be a module? I agree on the need to have a clear Service
Provider Interface which defines interfaces, abstract class
Github user jvz commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
If Lucene's API is anything like Elasticsearch, then they don't bother
changing the package name between major versions and there are hacky ways to
support multiple versions.
---
If your project
I also agree that modules should really stick to required dependencies.
As for only requiring log4j-core, the idea here is that you could still
just do:
compile 'org.apache.logging.log4j:log4j-core:2.+'
or whatever the equivalent is for your build system, and you'll still get
log4j-api and anyth
I think we should aim for all modules having only required dependencies.
We should not add any new optional dependencies, and all new modules should
only have required dependencies.
Maybe we won't be able to get rid of all optional dependencies in
log4j-core right away, though. Maybe we will rele
log4j-spi is to make a well-defined API for plugins including a
semantically versioned Appender, Filter, Layout, etc., interfaces and
abstract classes, along with the annotations and whatnot. It'd be treated
similarly to log4j-api in that regard.
On 25 April 2017 at 09:03, Gary Gregory wrote:
>
We should have consensus on the big picture here... are we all Ok with the
idea of all modules only having _required_ dependencies?
Gary
On Apr 25, 2017 6:57 AM, "Remko Popma" wrote:
> Nice analysis Mikael!
>
> I'm a bit fuzzy on log4j-spi, what was that for again? The list says "core
> will de
When adding new modules to the main repo, does each module need its own
site directory?
On Tue, Apr 25, 2017 at 4:02 PM, Mikael Ståldal
wrote:
> Yes, they should stay in the main repo, at least for the time being.
>
> On Tue, Apr 25, 2017 at 3:56 PM, Gary Gregory
> wrote:
>
>> And all of that s
Yes, they should stay in the main repo, at least for the time being.
On Tue, Apr 25, 2017 at 3:56 PM, Gary Gregory
wrote:
> And all of that should stay in the same repo IMO.
>
> Gary
>
> On Apr 25, 2017 2:51 AM, "Mikael Ståldal"
> wrote:
>
> > I guess that log4-core will become:
> >
> >- lo
Github user garydgregory commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
And maybe even log4j-lucene5...
---
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
Nice analysis Mikael!
I'm a bit fuzzy on log4j-spi, what was that for again? The list says "core will
depend on spi" but I think it's worth making an effort to ensure that basic
(file) logging behavior only needs core+API... Why does spi need to be
separated from core?
My first thought about
And all of that should stay in the same repo IMO.
Gary
On Apr 25, 2017 2:51 AM, "Mikael Ståldal" wrote:
> I guess that log4-core will become:
>
>- log4j-core (will depend on log4j-spi)
>- log4j-spi
>- log4j-csv
>- log4j-xml (XmlLayout)
>- log4j-json (JsonLayout)
>- log4j
[
https://issues.apache.org/jira/browse/LOG4J2-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982883#comment-15982883
]
Xavier Jodoin commented on LOG4J2-1854:
---
When you use the TCP endpoint graylog use
[
https://issues.apache.org/jira/browse/LOG4J2-1854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982877#comment-15982877
]
Mikael Ståldal commented on LOG4J2-1854:
In what context is this NULL delimiter n
[
https://issues.apache.org/jira/browse/LOG4J2-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reassigned LOG4J2-1889:
--
Assignee: Mikael Ståldal
> Move KafkaAppender to new module
>
Mikael Ståldal created LOG4J2-1889:
--
Summary: Move KafkaAppender to new module
Key: LOG4J2-1889
URL: https://issues.apache.org/jira/browse/LOG4J2-1889
Project: Log4j 2
Issue Type: Sub-task
Github user mikaelstaldal commented on the issue:
https://github.com/apache/logging-log4j2/pull/74
I suggest we place this in a new module "log4j-lucene" instead of in
log4j-nosql. We probably want to get rid of log4j-nosql, so we shouldn't put
new stuff in it.
---
If your project i
I guess that log4-core will become:
- log4j-core (will depend on log4j-spi)
- log4j-spi
- log4j-csv
- log4j-xml (XmlLayout)
- log4j-json (JsonLayout)
- log4j-yaml (YamlLayout)
- log4j-kafka
- log4j-smtp
- log4j-jms
- log4j-jdbc (or can this be kept in log4j-core?)
I don't think it will be more difficult to figure out which of the modules
to use, than to figure out which optional 3rd party dependencies they need
to include today.
On Mon, Apr 24, 2017 at 7:43 PM, Remko Popma wrote:
> How many new modules are we talking about, concretely?
>
> Matt mentioned
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982623#comment-15982623
]
Stefan Bodewig commented on LOG4NET-563:
There probably isn't any real reason to
[
https://issues.apache.org/jira/browse/LOG4NET-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982594#comment-15982594
]
Dominik Psenner commented on LOG4NET-563:
-
+1, and we may need shared issue track
GitHub user thuri opened a pull request:
https://github.com/apache/logging-log4j2/pull/75
trim levels read from properties file to remove trailing spaces
trim levels after reading them from properties and before initializing any
loggers.
If the level in a properties file co
41 matches
Mail list logo
