Nice.
Too bad that Jetty doesn't support automatic discovery of logging impl
as Tomcat do. Maybe we should issue a feature request about that?
On 2017-11-13 16:49, Gary Gregory wrote:
I also updated log4j-appserver/src/site/markdown/index.md.vm
Thank you!
Gary
On Mon, Nov 13, 2017 at 8:04
In
org.apache.logging.log4j.appserver.jetty.Log4j2Logger.PrivateManager.getContext():
Is this just a matter of changing false to true in:
public static LoggerContext getContext() {
final ClassLoader cl = Log4j2Logger.class.getClassLoader();
return
I will take a look...
On Nov 13, 2017 08:43, "Ralph Goers" wrote:
> Are you planning on fixing this?
>
> Ralph
>
> > On Nov 11, 2017, at 5:15 PM, Ralph Goers
> wrote:
> >
> > Because the caller of newLogger(name) is AbstractLogger its
I also updated log4j-appserver/src/site/markdown/index.md.vm
Thank you!
Gary
On Mon, Nov 13, 2017 at 8:04 AM, Gary Gregory
wrote:
> Oh, I added a section to the main index:
>
> #h3 Integrating with Application Servers
>
> Version 2.10.0 introduces a the module
Are you planning on fixing this?
Ralph
> On Nov 11, 2017, at 5:15 PM, Ralph Goers wrote:
>
> Because the caller of newLogger(name) is AbstractLogger its ClassLoader will
> always be used. You need the ClassLoader of the caller of getLogger().
>
> Ralph
>
>> On
Oh, I added a section to the main index:
#h3 Integrating with Application Servers
Version 2.10.0 introduces a the module log4j-appserver to improve
integration with Apache Tomcat and Eclipse Jetty.
Gary
On Sun, Nov 12, 2017 at 10:10 AM, Mikael Ståldal wrote:
> On 2017-11-12
On 2017-11-12 16:00, Gary Gregory wrote:
On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal wrote:
Do we want a package-info.java in the Jetty package, like in the Tomcat
package?
And you should probably add a section about Jetty integraion in
On Sun, Nov 12, 2017 at 7:25 AM, Mikael Ståldal wrote:
> Do we want a package-info.java in the Jetty package, like in the Tomcat
> package?
>
> And you should probably add a section about Jetty integraion in
> log4j-appserver/src/site/markdown/index.md.vm
Done. Please review.
Do we want a package-info.java in the Jetty package, like in the Tomcat
package?
And you should probably add a section about Jetty integraion in
log4j-appserver/src/site/markdown/index.md.vm
On 2017-11-11 23:43, Gary Gregory wrote:
Please code review git master. I'm not sure I have the class
Because the caller of newLogger(name) is AbstractLogger its ClassLoader will
always be used. You need the ClassLoader of the caller of getLogger().
Ralph
> On Nov 11, 2017, at 3:43 PM, Gary Gregory wrote:
>
> Please code review git master. I'm not sure I have the class
Please code review git master. I'm not sure I have the class loader right.
Gary
On Sat, Nov 11, 2017 at 2:54 PM, Ralph Goers
wrote:
> Oh, but you probably don’t want to extend AbstractLogger. You really want
> the FQCN of the caller to be able to identify the
Oh, but you probably don’t want to extend AbstractLogger. You really want the
FQCN of the caller to be able to identify the ClassLoader and LoggerContext to
use and you won’t get that from AbstractLogger’s getLogger method.
Ralph
> On Nov 11, 2017, at 2:45 PM, Ralph Goers
Sure. Look at TomcatLogger. It does exactly what you are trying to do.
Ralph
> On Nov 11, 2017, at 2:02 PM, Gary Gregory wrote:
>
> The Javadoc for Log4j's LoggerAdapter says "This registry should not be
> used for Log4j Loggers; it is instead used for creating bridges
The Javadoc for Log4j's LoggerAdapter says "This registry should not be
used for Log4j Loggers; it is instead used for creating bridges to other
external log systems.".
In this case we are not bridging TO another log system. We are plugging
INTO Jetty's log system and subclassing Jetty's own
Wouldn't this implementation contain incorrect caller location information?
On 10 November 2017 at 19:25, wrote:
> Repository: logging-log4j2
> Updated Branches:
> refs/heads/master aad2f132b -> 7d52f131e
>
>
> [LOG4J2-2114] Provide a native Log4j 2 implementation of
15 matches
Mail list logo