WebLogic and WebSphere come to mind, particularly when trying to use log4j in the server lib instead of just a war.
On 21 September 2014 19:51, Remko Popma <[email protected]> wrote: > I see. > My 2c: we have documented the current behaviour and haven't had any > complaints so there's not much reason to change it. This error, if it > happens, happens at deploy time so the users will very likely notice & take > action. We could change this to just log the error, I'd be fine with that > too. (I do hope it's not a lot of work or results in complex code.) > > Different question: what exotic web containers and why does log4j-web need > to be more flexible? > > Sent from my iPhone > > On 2014/09/22, at 9:02, Matt Sicker <[email protected]> wrote: > > Well, as it is now, if this fails, everything fails (until an exception is > caught or the main method lets it go). I could probably modify this to not > fail like that if it can't initialize and just fall back to the default > configuration and such like we normally do. I'm currently refactoring > log4j-web quite a bit to make it more flexible in exotic servlet containers > and such where custom programmatic configuration may be required (i.e., set > up a ConfigurationSource with a custom class). > > On 21 September 2014 18:37, Remko Popma <[email protected]> wrote: > >> In other places the log4j policy is that logging config errors or errors >> during logging should not impact the application unless the user asked for >> it (as in audit logging). >> >> So, logging the error would be consistent with that. On the other hand we >> haven't had any complaints... >> >> If this fails though, would calls to logger methods be silently ignored >> or what would happen? >> (Is it even possible to log the problem and keep on truckin'? ) >> >> Sent from my iPhone >> >> On 2014/09/22, at 8:28, Matt Sicker <[email protected]> wrote: >> >> Well, the way the code currently is written, it looks like it does indeed >> throw an exception which would propagate upward to the >> ServletContextListener or ServletContainerListener, so it's still correct. >> Perhaps it shouldn't actually do that and just log an error? >> >> On 21 September 2014 18:22, Remko Popma <[email protected]> wrote: >> >>> The docs say >>> > otherwise, the application will fail to start with an exception. >>> >>> Is this true? Or should that be ...logging will fail to start with an >>> exception. >>> >>> Sent from my iPhone >>> >>> > On 2014/09/22, at 8:09, [email protected] wrote: >>> > >>> > Doc update regarding how servlet contexts can be named. >>> > >>> > >>> > Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo >>> > Commit: >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/3c868456 >>> > Tree: >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/3c868456 >>> > Diff: >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/3c868456 >>> > >>> > Branch: refs/heads/master >>> > Commit: 3c868456ed043673a889cdcd0afe3513a695dd72 >>> > Parents: 0e5cc42 >>> > Author: Matt Sicker <[email protected]> >>> > Authored: Sun Sep 21 17:21:07 2014 -0500 >>> > Committer: Matt Sicker <[email protected]> >>> > Committed: Sun Sep 21 17:21:07 2014 -0500 >>> > >>> > ---------------------------------------------------------------------- >>> > src/site/xdoc/manual/webapp.xml | 12 +++++++----- >>> > 1 file changed, 7 insertions(+), 5 deletions(-) >>> > ---------------------------------------------------------------------- >>> > >>> > >>> > >>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/3c868456/src/site/xdoc/manual/webapp.xml >>> > ---------------------------------------------------------------------- >>> > diff --git a/src/site/xdoc/manual/webapp.xml >>> b/src/site/xdoc/manual/webapp.xml >>> > index ecad1f9..1b86d45 100644 >>> > --- a/src/site/xdoc/manual/webapp.xml >>> > +++ b/src/site/xdoc/manual/webapp.xml >>> > @@ -177,17 +177,19 @@ >>> > <subsection name="Context Parameters"> >>> > <a name="ContextParams" /> >>> > <p> >>> > - By default, Log4j 2 uses the <code>ServletContext</code>'s >>> context name as the <code>LoggerContext</code> name >>> > - and uses the standard pattern for locating the Log4j >>> configuration file. There are three context parameters >>> > - that you can use to control this behavior. The first, >>> <code>isLog4jContextSelectorNamed</code>, specifies >>> > - whether the context should be selected using the >>> > + By default, Log4j 2 uses the <code>ServletContext</code>'s >>> > + <a href=" >>> http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html#getServletContextName()">context >>> name</a> >>> > + as the <code>LoggerContext</code> name and uses the >>> standard pattern for locating the Log4j configuration >>> > + file. There are three context parameters that you can use >>> to control this behavior. The first, >>> > + <code>isLog4jContextSelectorNamed</code>, specifies whether >>> the context should be selected using the >>> > <a class="javadoc" >>> href="../log4j-core/apidocs/org/apache/logging/log4j/core/selector/JndiContextSelector.html" >>> >> JndiContextSelector</a>. If <code>isLog4jContextSelectorNamed</code> >>> is not specified or is anything other >>> > than <code>true</code>, it is assumed to be >>> <code>false</code>. >>> > </p> >>> > <p> >>> > If <code>isLog4jContextSelectorNamed</code> is >>> <code>true</code>, <code>log4jContextName</code> must be >>> > - specified; otherwise, the application will fail to start >>> with an exception. <code>log4jConfiguration</code> >>> > + specified or <code>display-name</code> must be specified in >>> <code>web.xml</code>; otherwise, the application >>> > + will fail to start with an exception. >>> <code>log4jConfiguration</code> >>> > <em>should</em> also be specified in this case, and must be >>> a valid URI for the configuration file; however, >>> > this parameter is not required. >>> > </p> >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
