Re: Java Servlet request log using log4j2

As https://issues.apache.org/jira/browse/LOG4J2-1492 hasn't got enough traction, we have implemented jetty's RequestLog using log4j2 for our use case. *MVN Dependency:* com.flipkart.poseidon log4j-access 5.0.0-SNAPSHOT *Sample code:* RequestLogHandler requestLogHandler = new Request

What happens if I do NOT add the listener and filter in a servlet 2.5 webapp?

I'm looking at running a webapp in a version of WebLogic that appears to only support (at maximum) the Servlet 2.5 spec. The Log4j2 docs talk about using Log4j2 in a Servlet 2.5 container, at https://logging.apache.org/log4j/2.x/manual/webapp.html#Servlet-2.5 . This page says the following: "I

Re: What happens if I do NOT add the listener and filter in a servlet 2.5 webapp?

It's to automatically shut down the LoggerContext when you undeploy a webapp. If you don't undeploy or redeploy webapps, you don't really need to use it. On 6 September 2016 at 10:22, KARR, DAVID wrote: > I'm looking at running a webapp in a version of WebLogic that appears to > only support (at

Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

The API module method org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) is @since 2.7 and is only called from the Core module. I propose we move it to Core. Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

Re: Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

Might as well. If we need it in api, we can move it back later. On 6 September 2016 at 15:54, Gary Gregory wrote: > The API module method > org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) is > @since > 2.7 and is only called from the Core module. I propose we move it to Core. >

Re: Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

Is there a problem that needs solving here? I know we consider the API module's util package private, but I really don't like making changes that could break user code for no good reason... Sent from my iPhone > On 2016/09/07, at 6:36, Matt Sicker wrote: > > Might as well. If we need it in api

Re: Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

How could moving an API marked @since 2.7 break user code? Gary On Tue, Sep 6, 2016 at 6:34 PM, Remko Popma wrote: > Is there a problem that needs solving here? > I know we consider the API module's util package private, but I really > don't like making changes that could break user code for no

Re: Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

Ah! I didn't look at the code. If there's no risk of breaking user code I have no objection. Apologies. Sent from my iPhone > On 2016/09/07, at 8:11, Gary Gregory wrote: > > How could moving an API marked @since 2.7 break user code? > > Gary > >> On Tue, Sep 6, 2016 at 6:34 PM, Remko Popm

Re: Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

Hm, that methods depends on the package private class LowLevelLogUtil. So moving the method to Core would mean making LowLevelLogUtil public. I'm not sure that's a good tradeoff... Gary On Tue, Sep 6, 2016 at 7:44 PM, Remko Popma wrote: > Ah! I didn't look at the code. If there's no risk of bre

Re: Move org.apache.logging.log4j.util.LoaderUtil.isClassAvailable(String) to Core?

If you move it to Loader, you can just use StatusLogger. LowLevelLogUtil is there for the classes that have to load before StatusLogger can properly load. On 6 September 2016 at 21:08, Gary Gregory wrote: > Hm, that methods depends on the package private class LowLevelLogUtil. So > moving the me