I didn’t realize that java.base was that limited. Are these all required at run
time or only build? For example, the annotation processor is not used when
log4j is running so I would suspect it is required to be present in the build
and I would think it would have to be present when the compiler
> On Jan 28, 2018, at 9:22 PM, Matt Sicker wrote:
>
> XML configuration requires the java.xml module which is a dependency to
> consider now.
Really? That sucks.
Ralph
That's rather limiting. Here's what we're already using:
* java.compiler: annotation processing (could potentially be split, but
this situation is already confusing enough for users)
* java.management: JMX
* java.naming: JNDI
* java.scripting: javascript/groovy/etc plugins
* java.xml: XML configur
XML configuration requires the java.xml module which is a dependency to
consider now.
I like the finer grained names.
On 28 January 2018 at 22:17, Gary Gregory wrote:
> Beyond these moves, the next slice and dice would be to deal with our XML,
> JSON, and YAML dependencies:
>
> We have no depen
Beyond these moves, the next slice and dice would be to deal with our XML,
JSON, and YAML dependencies:
We have no dependencies to read an XML configuration.
For JSON and YAML configs, we use Jackson.
For XML, JSON, and YAML layouts we use Jackson.
We could spit things out like this:
log4j-jso
On Sun, Jan 28, 2018 at 2:25 PM, Ralph Goers
wrote:
> I should add that each module must have a unique package hierarchy so, in
> general, the package names should be org.apache.logging.log4j.modulename.
> In this case it would be org.apache.logging.log4j.jeromq.apppender. The
> mom package prob
On Sun, Jan 28, 2018 at 4:24 PM, Remko Popma wrote:
> I went ahead and changed the epic link on the JIRA tickets related to
> splitting off sub modules. Hope you don’t mind.
>
Great, thank you. I do not mind at all :-)
Gary
>
> On Mon, Jan 29, 2018 at 7:16 Remko Popma wrote:
>
> > Gary,
> >
>
I went ahead and changed the epic link on the JIRA tickets related to
splitting off sub modules. Hope you don’t mind.
On Mon, Jan 29, 2018 at 7:16 Remko Popma wrote:
> Gary,
>
> Would you mind changing the epic link of these and future JIRA tickets to
> https://issues.apache.org/jira/browse/LOG4
I actually coded it this way deliberately.
The local variables clarify the intention and make the code self documenting.
Without the variable the reader needs to spend effort to understand the
calculation on the right.
I got this technique from Kent Beck’s Implementation Patterns and Robert
M
Gary,
Would you mind changing the epic link of these and future JIRA tickets to
https://issues.apache.org/jira/browse/LOG4J2-2226 (Log4j core modularization)?
That’s a nice way to link them together.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 29, 2018, at
Our release notes are going to need a section “Potential breaking changes”.
We should start tracking these before we forget.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 29, 2018, at 6:25, Ralph Goers wrote:
>
> I should add that each module must have a uni
I should add that each module must have a unique package hierarchy so, in
general, the package names should be org.apache.logging.log4j.modulename. In
this case it would be org.apache.logging.log4j.jeromq.apppender. The mom
package probably has no value.
Ralph
> On Jan 28, 2018, at 2:23 PM, R
Any component that is not in the core module MUST NOT use the core package.
That would make it impossible to package them as Java 9 modules.
Ralph
> On Jan 28, 2018, at 11:31 AM, Gary Gregory wrote:
>
> Hi All,
>
> Now that the ZeroMQ via JeroMQ support is in its own module log4j-jeromq, I
>
Hi All,
Now that the ZeroMQ via JeroMQ support is in its own module log4j-jeromq, I
wonder if the Java package should change from
org.apache.logging.log4j.core.appender.mom.jeromq
to
org.apache.logging.log4j.appender.mom.jeromq
?
Same for the recently moved JPA appender.
Same for impending m
Random fails starting with
https://builds.apache.org/user/ggregory/my-views/view/Logging/job/Log4j%202.x/3340/
Any thoughts?
Gary
Thanks for the clarification! Good to hear.
On Sun, Jan 28, 2018 at 11:34 PM, wrote:
> This was a local issue. Something was corrupt about the core jar and once
> I replaced it with a known good file things worked as expected.
>
> Apologies if anybody wasted time looking into this non-issue.
>
>
This was a local issue. Something was corrupt about the core jar and once I
replaced it with a known good file things worked as expected.
Apologies if anybody wasted time looking into this non-issue.
Thanks
Mark
-Original Message-
From: Matt Sicker [mailto:boa...@gmail.com]
Sent: Sa
On 2018-01-21, Dominik Psenner wrote:
> Sometimes it is possible to configure the test runner so that it runs in
> process instead of spawning a new process. Would you like to investigate on
> this?
I don't see any such option. We could re-enable more detailed logging
and try to figure out which
On 2018-01-21, Dominik Psenner wrote:
> On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" wrote:
>> Maybe, yes. See the other thread for my investigation so far. The
>> github issue I've linked and the source code for the Unix
>> implementation of FileStream state that FileShare.None is the only
>> th
19 matches
Mail list logo
