Log4j 2
  1. Log4j 2
  2. LOG4J2-554

No easy way to point to a configuration file in the WEB-INF folder

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta9
    • Fix Version/s: 2.0-rc2
    • Component/s: Configurators
    • Labels:
      None
    • Environment:

      WildFly 8.0.0, JDK 1.7.0_45, WIn7

      Description

      I am trying to put all of my configuration files under WEB-INF/config folder but there is no way (other than an explicit reference to my file system) to set the log4jConfiguration to point to that. It also does not report any errors when it can't find the file log4jConfiguration (unless there is a URI reference error) so you are scratching your head when it does nothing.

        Activity

        Hide
        Remko Popma added a comment -

        I know anything you put under WEB-INF/classes is in the classpath, and jar/zip files under WEB-INF/lib are added to the classpath, but I'm not aware of any similar convention for WEB-INF/config. Is this folder treated as special by the web container?

        Show
        Remko Popma added a comment - I know anything you put under WEB-INF/classes is in the classpath, and jar/zip files under WEB-INF/lib are added to the classpath, but I'm not aware of any similar convention for WEB-INF/config. Is this folder treated as special by the web container?
        Hide
        Russell J. Nile added a comment -

        Remko,
        There is nothing significant about the 'config' folder (personal convention), but I am able to specify "/WEB-INF/config/applicationContext.xml" in the web.xml for Spring and it finds the configuration file just fine:    <context-param>
                <param-name>contextConfigLocation</param-name>
                <param-value>
                    /WEB-INF/config/applicationContext.xml
                </param-value>
            </context-param>
        it generally treats the leading "/" as the root of the war file.
        My hopes was that the log4jconfiguration would work similarly:    <context-param>
                <param-name>log4jConfiguration</param-name>
                <param-value>/WEB-INF/config/log4j2.xml</param-value>
            </context-param>
        but it does not find the configuration file nor does it report that it can't find it....it just doesn't work.

        I also tried this with rc1 and the same result (although it seems to behave a bit more consistently than with beta9...I used to get notices about a bad URI).
        NOTE: I do see this message when using rc1 that I don't remember when I used beta9...should I open another ticket for that?:    10:46:20,606 ERROR [stderr] (default task-3) ERROR StatusLogger Could not search jar file 'C:\dev\wildfly-8.0.0.Final\standalone\deployments\CTMSApplicationServices.war\WEB-INF\lib\log4j-core-2.0-rc1.jar\org\apache\logging\log4j\core' for classes matching criteria: annotated with @Plugin file not found
        It seems I only see this when I have the <param-name>log4jConfiguration</param-name> in the web.xml though. 
        When I put the log4j2.xml in the classpath (/classes) everything works fine....but I like putting my configuration files all together.

        Show
        Russell J. Nile added a comment - Remko, There is nothing significant about the 'config' folder (personal convention), but I am able to specify "/WEB-INF/config/applicationContext.xml" in the web.xml for Spring and it finds the configuration file just fine:    <context-param>         <param-name>contextConfigLocation</param-name>         <param-value>             /WEB-INF/config/applicationContext.xml         </param-value>     </context-param> it generally treats the leading "/" as the root of the war file. My hopes was that the log4jconfiguration would work similarly:    <context-param>         <param-name>log4jConfiguration</param-name>         <param-value>/WEB-INF/config/log4j2.xml</param-value>     </context-param> but it does not find the configuration file nor does it report that it can't find it....it just doesn't work. I also tried this with rc1 and the same result (although it seems to behave a bit more consistently than with beta9...I used to get notices about a bad URI). NOTE: I do see this message when using rc1 that I don't remember when I used beta9...should I open another ticket for that?:    10:46:20,606 ERROR [stderr] (default task-3) ERROR StatusLogger Could not search jar file 'C:\dev\wildfly-8.0.0.Final\standalone\deployments\CTMSApplicationServices.war\WEB-INF\lib\log4j-core-2.0-rc1.jar\org\apache\logging\log4j\core' for classes matching criteria: annotated with @Plugin file not found It seems I only see this when I have the <param-name>log4jConfiguration</param-name> in the web.xml though.  When I put the log4j2.xml in the classpath (/classes) everything works fine....but I like putting my configuration files all together.
        Hide
        Remko Popma added a comment -

        log4jConfiguration is the old log4j-1.2 system property name. Log4j2 uses a different system property name, log4j.configurationFile to specify the config file location.

        Also, I think it is fine for a web container to decide that /WEB-INF means the WEB-INF folder under the root of a war file, but I don't think you can ask log4j to look at the world that way. The root is the root of the file system, I think.

        About the error message, that does sound like a separate issue.

        Show
        Remko Popma added a comment - log4jConfiguration is the old log4j-1.2 system property name. Log4j2 uses a different system property name, log4j.configurationFile to specify the config file location. Also, I think it is fine for a web container to decide that /WEB-INF means the WEB-INF folder under the root of a war file, but I don't think you can ask log4j to look at the world that way. The root is the root of the file system, I think. About the error message, that does sound like a separate issue.
        Hide
        Russell J. Nile added a comment -

        Remko,
        It appears there is an inconsistency here; the log4j2 documentation specifies to use 'log4jConfiguration' (see:[1]http://logging.apache.org/log4j/2.x/manual/webapp.html#ContextParams) .  If I use the 'log4jConfiguration'and point to a physical location on my file system it does work.  The following in the web.xml works just fine.
            <context-param>
                <param-name>log4jConfiguration</param-name>
                 <param-value>file://c:/projects/SMS-CTMSApplication/CTMSApplicationServices/WebContent/WEB-INF/config/log4j2.xml</param-value> 
            </context-param>

        I understand how Log4J2 can not be customized for the web space per se (although the unique web-context key word 'log4jConfiguration' implies there is some web influence, or maybe that is just left over), but I think others will have a similar desire to do this. 
        I am going to see if there is an environment variable I can use that might help me (e.g.: $

        {CurrentWARDirectory}

        )

        Show
        Russell J. Nile added a comment - Remko, It appears there is an inconsistency here; the log4j2 documentation specifies to use 'log4jConfiguration' (see: [1] http://logging.apache.org/log4j/2.x/manual/webapp.html#ContextParams) .  If I use the 'log4jConfiguration'and point to a physical location on my file system it does work.  The following in the web.xml works just fine.     <context-param>         <param-name>log4jConfiguration</param-name>          <param-value> file://c:/projects/SMS-CTMSApplication/CTMSApplicationServices/WebContent/WEB-INF/config/log4j2.xml </param-value>      </context-param> I understand how Log4J2 can not be customized for the web space per se (although the unique web-context key word 'log4jConfiguration' implies there is some web influence, or maybe that is just left over), but I think others will have a similar desire to do this.  I am going to see if there is an environment variable I can use that might help me (e.g.: $ {CurrentWARDirectory} )
        Hide
        Ralph Goers added a comment -

        If the container you are running in exposes a system property then you can easily achieve what you want. For example, in Tomcat you could specifiy $

        {env:catalina.home}

        /webapps/CTMSApplicationServices/WEB-INF/config/log4j2.xml.

        That said, we could be doing getServletContext().getResourceAsStream(getServletContext().getInitParameter("log4jConfiguration")); which would allow exactly what you want. I will take a look at the code and see if we can easily do that.

        Show
        Ralph Goers added a comment - If the container you are running in exposes a system property then you can easily achieve what you want. For example, in Tomcat you could specifiy $ {env:catalina.home} /webapps/CTMSApplicationServices/WEB-INF/config/log4j2.xml. That said, we could be doing getServletContext().getResourceAsStream(getServletContext().getInitParameter("log4jConfiguration")); which would allow exactly what you want. I will take a look at the code and see if we can easily do that.
        Hide
        Russell J. Nile added a comment -

        I am poking around for something like that.  We are using WildFly and have a lot of jboss variables that point to the basic location....but I am looking for something a tad more elegant.  In this case my application would have to know about how the appserver is going to deploy it (although it is a pretty safe assumption).  It would look like this for me:     $

        {jboss.server.base.dir}

        /deployments/CTMSApplicationServices.war/WEB-INF/config/log4j2.xml.
        The use of the Servlet context may work...but then there is some web-app specific notion inside log4j...dunno if that is something you want to avoid.

        Show
        Russell J. Nile added a comment - I am poking around for something like that.  We are using WildFly and have a lot of jboss variables that point to the basic location....but I am looking for something a tad more elegant.  In this case my application would have to know about how the appserver is going to deploy it (although it is a pretty safe assumption).  It would look like this for me:     $ {jboss.server.base.dir} /deployments/CTMSApplicationServices.war/WEB-INF/config/log4j2.xml. The use of the Servlet context may work...but then there is some web-app specific notion inside log4j...dunno if that is something you want to avoid.
        Hide
        Ralph Goers added a comment -

        We already have some webapp specific stuff. We have to to read the log4jConfiguration value from the web.xml. What we don't want is something specific to a particular container. If you are deploying a war in JBoss trying to read from the location of the deployed war is generally a bad idea.

        Show
        Ralph Goers added a comment - We already have some webapp specific stuff. We have to to read the log4jConfiguration value from the web.xml. What we don't want is something specific to a particular container. If you are deploying a war in JBoss trying to read from the location of the deployed war is generally a bad idea.
        Hide
        Russell J. Nile added a comment -

        Good point on the web.xml.

        Agreed on the reading from the war location...I want this to be as
        portable as possible and that has potential problems written all over it.

        If the getServletContext allows you to read from something relative to
        the war itself, that would be dynamite. It would serve my purpose
        wonderfully.

        I didn't try *./*WEB-INF/config/log4j2.xml (use the preceding '.' to
        ensure current)...think that might get me further? I may try that.

        Show
        Russell J. Nile added a comment - Good point on the web.xml. Agreed on the reading from the war location...I want this to be as portable as possible and that has potential problems written all over it. If the getServletContext allows you to read from something relative to the war itself, that would be dynamite. It would serve my purpose wonderfully. I didn't try *./*WEB-INF/config/log4j2.xml (use the preceding '.' to ensure current)...think that might get me further? I may try that.
        Hide
        Ralph Goers added a comment -

        Fix committed in revision 1601520. Configuration files may now be located as servlet context resources when running in a web application.

        Please verify and close.

        Show
        Ralph Goers added a comment - Fix committed in revision 1601520. Configuration files may now be located as servlet context resources when running in a web application. Please verify and close.

          People

          • Assignee:
            Ralph Goers
            Reporter:
            Russell J. Nile
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development