ri, Oct 5, 2018 at 1:58 PM Ralph Goers <mailto:rgo...@apache.org>> wrote:
> I didn’t write this particular test. I will have to find it.
>
> I'm curious to see the test as well, especially to see what the
> "defaultJava8" test is. Is that a method for getting th
> On Oct 5, 2018, at 10:54 AM, David Lloyd wrote:
>
> On Fri, Oct 5, 2018 at 10:12 AM Ralph Goers wrote:
>>> On Oct 5, 2018, at 1:10 AM, Luke Hutchison wrote:
>>>
>>> On Thu, Oct 4, 2018, 10:27 PM Ralph Goers >> <mailto:rgo...@apache.org>&g
ifferent Ns and
> also entire stack?
>
> Mandy
>
> On 10/4/18 9:46 PM, Ralph Goers wrote:
>> I should have rephrased this. We cannot assume that the caller of the Log4j
>> API method is the caller we need. It might be another Log4j API method or
>> another l
> On Oct 5, 2018, at 1:10 AM, Luke Hutchison wrote:
>
> On Thu, Oct 4, 2018, 10:27 PM Ralph Goers <mailto:rgo...@apache.org>> wrote:
> Yes, we have found in some situations using the SecurityManager is faster
> than StackWalker.
>
> This is interesting -- how
tps://lists.apache.org/thread.html/29ca67b98c8a508f2836301ac33747b72ca0ce86f69f466073412bfc@%3Cdev.logging.apache.org%3E>
Ralph
> On Oct 4, 2018, at 9:25 PM, Ralph Goers wrote:
>
> Unfortunately, we can’t use getCallerClass. Some API methods can be called by
> users of the API or by ot
oking for the immediate caller, you can try
> StackWalker::getCallerClass which only walks the top few
> frames and intends to be lower cost.
>
> Mandy
>
> On 10/4/18 2:04 PM, Ralph Goers wrote:
> > Hmm, it would probably be a safe assumption that a Logger will never be
>
s which only walks the top few
> frames and intends to be lower cost.
>
> Mandy
>
> On 10/4/18 2:04 PM, Ralph Goers wrote:
>> Hmm, it would probably be a safe assumption that a Logger will never be used
>> outside of the module. That isn’t true of the class name, method n
thinking about capturing the call stack when you create the logger (to
> get the module), not when you call the logger.
>
> cheers,
> Rémi
>
> - Mail original -
>> De: "Ralph Goers"
>> À: "Alex Sviridov"
>> Cc: "Remi Forax&quo
I will take a look and see what tests we have.
Ralph
> On Oct 3, 2018, at 10:38 AM, Alan Bateman wrote:
>
> On 03/10/2018 17:26, Ralph Goers wrote:
>> Log4j handles this by capturing the fully qualified class name of the
>> logging adapter. Obviously, this doesn’t work i
Log4j handles this by capturing the fully qualified class name of the logging
adapter. Obviously, this doesn’t work if the adapter doesn’t pass Log4j the
FQCN, but it does work for the adapters we support. That said, it is very slow
to capture this and is probably the biggest pain point. Log4j
> On Sep 30, 2018, at 12:34 AM, Alan Bateman wrote:
>
> On 29/09/2018 20:25, Ralph Goers wrote:
>> Following advice I received on this list, the Log4j API jar is defined as a
>> multi-release jar with the module-info.java file placed in
>> META-INF/versions/9. Th
> On Sep 30, 2018, at 12:34 AM, Alan Bateman wrote:
>
> On 29/09/2018 20:25, Ralph Goers wrote:
>> Following advice I received on this list, the Log4j API jar is defined as a
>> multi-release jar with the module-info.java file placed in
>> META-INF/versions/9. Th
Following advice I received on this list, the Log4j API jar is defined as a
multi-release jar with the module-info.java file placed in META-INF/versions/9.
This should work fine, yet we continue to have users who are complaining about
various tools, such as Javadoc and Eclipse, that can’t handle
I had this same thought a week or so ago and I wouldn’t be surprised to see
someone create a framework that generates a module-info.java from annotations.
But that doesn’t solve the issues I have hit, which all stem from
module-info.class conflicting with pre-java 9 tools. Frankly, I don’t know
s before computing the OSGi manifest, and only compile them before
> building the jar.
>
> Russ
>
>> On May 17, 2017, at 11:28 PM, Ralph Goers > <mailto:rgo...@apache.org>> wrote:
>>
>> I am afraid I have to echo these sentiments to some degree. In trying to
I am afraid I have to echo these sentiments to some degree. In trying to get
Log4j to support Java 9 I first tried to use a multi-release jar. This failed
miserably when the OSGi build tool failed over finding java classes under
META-INF. Then it proceeded to complain about the module-info.java
> On May 9, 2017, at 11:50 PM, Remi Forax wrote:
>
>
>
> On May 10, 2017 2:20:31 AM GMT+02:00, Ralph Goers <mailto:rgo...@apache.org>> wrote:
>>
>>
>> With all this in mind, if users create modules will they be required to
>> declare the p
> On May 9, 2017, at 3:39 PM, Alex Buckley wrote:
>
> On 5/9/2017 3:04 PM, Ralph Goers wrote:
>> Pardon me for being dense, but my reading said that Java modules
>> disallowed runtime cycles as well as compile time. Once LoggerFinder
>> binds with the module that prov
> On May 9, 2017, at 12:50 PM, Jochen Theodorou wrote:
>
> On 09.05.2017 20:51, Ralph Goers wrote:
>
>> We also noticed that System.LoggerFinder [1] now provides a new way
>> to integrate an external logging framework with Java. If Log4j
>> creates the service p
I am attempting to modularize Log4j and am running into some trouble
understanding how this can work.
Log4j supports many Appenders, such as the FlumeAppender, KafkaAppender,
CassandraAppender, and JPAAppender. Each of these use their respective
libraries to cause the log events to be delivered
20 matches
Mail list logo
