9 Replies Latest reply on Jun 10, 2016 5:45 PM by cmrozien

    How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?

    cmrozien

      Hi,

       

      I've read the many discussions that have concluded that logging from static module shared classes doesn't work when configuring logging on a per application basis (e.g. log4j.xml file inside application's war file).  It sounds like this is because the first application that gets deployed initializes the static Logger variable inside the static module class that is then shared by all applications.

       

      So now I am trying to use the standalone.xml logging-profile approach for each of my applications and just configure a single shared "PLATFORM" logger at the server level.  My expectation is that the log entries logged by each application would go into each application's log file, but the log entries logged by the shared classes would go into my single shared "PLATFORM" log file.  However, that is not what happens.  I am not seeing any of the log entries from the shared classes in any log file.  And, all of my System.out.println messages invoked by my applications have also disappeared.

       

      I think I am running into the LOGMGR-111 issue?  I noticed that WildFly 8.2.1 doesn't have this fix, even though WildFly shipped a year and a half after the fix was merged.  So, I tried to overwrite the jboss-logmanager-1.5.2.Final-sources.jar that came with WildFly 8.2.1 with version jboss-logmanager-1.5.3.Final-sources.jar and change the module.xml to reference the newer jar file.  This didn't work and debugging has revealed that WildFlyLogContextSelectorImpl.java is what instantiates the ClassLoaderLogContextSelector object that was fixed.  And it looks like the WildFlyLogContextSelectorImpl.class file is packaged in wildfly-logging-8.2.1.Final.jar.  But, I have not been able to find a newer version of this wildfly jar that calls the fixed ClassLoaderLogContextSelector constructor.

       

      I'm relatively new at working with WildFly and the process of obtaining patches for open source code.  Is there a standard way of getting a patch or fix for LOGMGR-111 into WildFly 8.2.1?

       

      Thanks for the help.

       

      -Cheryl

        • 1. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
          nickarls

          It might be a bit tricky to get fixes for versions as old as that if the interface has changed so that it's not a simple matter of swapping out a jar in a module

          • 2. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
            cmrozien

            Does anyone have any logging configuration design recommendations that work given the below requirements?  Depending on the amount of work involved, it might be possible to update our software to a new WildFly version.  When I did a quick search of the WildFly source code for these newer versions, I didn't find any calls to the ClassLoaderLogContextSelector constructor.  Do these newer WildFly versions use the JBoss Logging Subsystem?  The WildFly logging documentation sounds like it does.

             

            Some of my requirements are as follows:

            • Application developers should have the ability to provide their own log4j configuration file inside their war to avoid making developers edit the server's configuration file, which lives in a completely separate git repository (e.g. decouple all application code from server code).
            • End users should be able to change the logging level at runtime without having to restart the server.  Users can do this either using a UI page, manually editing a configuration file, and/or using a CLI.
            • Log entries for shared API code (e.g. static modules) should be written to the log file of the application that called the API.  Given that this does not seem possible, what other options are available?

             

            So far, I've tried the "Per Deployment Logging" approach and the "Logging Profile" approach.   And, reading the JBoss and WildFly documentation seemed to point me in the direction of these two approaches.

             

            Thanks again for any advice or pointers people may have.

             

            -Cheryl

            • 3. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
              cmrozien

              I guess I'll try a more basic question: Does anyone know if LOGMGR-111 issue is fixed in any version of WildFly, or know of a better place to ask this question?

               

              Thanks.

               

              -Cheryl

              • 4. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
                nickarls

                It is marked as "Done", fix version is 2.0.0.Beta1 and WildFly 10 uses 2.0.3.Final so it might be worth a try.

                • 5. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
                  cmrozien

                  Thank you for the response.  I'll give it a try.

                  • 6. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
                    jamezp

                    If you're using a per-application approach, e.g. logging configuration file embedded in the deployment, users will not be able to make runtime changes. This is where logging profiles are likely a good fit. If the System.xxx.print() statements are not working on a logging profile that sounds like a bug.

                     

                    • Log entries for shared API code (e.g. static modules) should be written to the log file of the application that called the API.  Given that this does not seem possible, what other options are available?

                    By API code do you mean your API or things like JPA, JSF, etc.?

                     

                    --

                    James R. Perkins

                    • 7. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
                      cmrozien

                      Regarding the missing System.out.println(), I'm assuming this is because WildFly 8.2.1 doesn't have the fix for LOGMGR-111.  I purposely didn't add a root-logger to my "sample" logging-profile because I wanted all System.out.println() statements to use the server's root logger that sends these statements to server.log & the WildFly console.

                       

                                      <logging-profile name="sample">

                                          <size-rotating-file-handler name="SIZE" autoflush="true">

                                              <level name="DEBUG"/>

                                              <file relative-to="jboss.server.log.dir" path="samplePRF.log"/>

                                              <append value="true"/>

                                          </size-rotating-file-handler>

                                          <logger category="com.dell.dsm.sample" use-parent-handlers="false">

                                              <level name="DEBUG"/>

                                              <handlers>

                                                  <handler name="SIZE"/>

                                              </handlers>

                                          </logger>

                                      </logging-profile>

                       

                      Regarding APIs that our applications call, I mean any API that can be called by more than one application.  Some APIs being called by our applications are our own APIs we've bundled into static modules, and some are 3rd party APIs, which can be almost anything that an application needs.  For example I tried calls to HttpClient, HttpPost, HttpResponse APIs found in the org.apache.httpcomponents:4.3 static module, but these are only a few of the many 3rd APIs being called.

                       

                      Thanks for any recommendations you may have.

                       

                      -Cheryl

                      • 8. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
                        jamezp

                        I purposely didn't add a root-logger to my "sample" logging-profile because I wanted all System.out.println() statements to use the server's root logger that sends these statements to server.log & the WildFly console.

                        Ah, that won't quite work. Each logging profile gets it's own log context which is means it has it's own logging configuration. At this point, though it's something I've considered, log contexts don't inherit configurations from other log contexts.

                         

                        Generally speaking static modules will log to the system log context. Even if a new instance of an object is created by each deployment associated with a logging profile since the module uses it's own class loader it would log to the default log context.

                         

                        The fix for LOGMGR-111 was really a fix for JSP's as a child class loader is created. Deployments do not have static modules set as their parent class loader so it won't work like you were hoping unfortunately.

                         

                        Feel free to file an issue with what you're looking for. There has been some similar requests to this so it might be something worth looking at. There's likely not a lot that can be done where a static module would log to a deployments log context however. One option for that though might be some kind of filter routing. I haven't really thought that through though.

                         

                        --

                        James R. Perkins

                        • 9. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
                          cmrozien

                           

                          I purposely didn't add a root-logger to my "sample" logging-profile because I wanted all System.out.println() statements to use the server's root logger that sends these statements to server.log & the WildFly console.

                          Ah, that won't quite work. Each logging profile gets it's own log context which is means it has it's own logging configuration. At this point, though it's something I've considered, log contexts don't inherit configurations from other log contexts.

                           

                          Does this mean it's okay to have a root-logger in one or more logging-profiles that use a handler that logs to the same server.log file that the system log context's root-logger is logging to?  Or, will there be locking/file contention issues on the server.log file?

                           

                          Generally speaking static modules will log to the system log context. Even if a new instance of an object is created by each deployment associated with a logging profile since the module uses it's own class loader it would log to the default log context.

                           

                          If I'm understanding what you mean by system log context (or default log context), shouldn't calls to org.apache.http APIs be logged to PLATFORM.log, given the following standalone.xml logging configuration?  I can't find any org.apache.http log entries in any log file when my deployment references the "sample" logging-profile.  However, if I remove the "sample" logging-profile reference from the deployment's MANIFEST.MF, then the org.apache.http log entries do show up in PLATFORM.log.  What am I missing?

                           

                                <subsystem xmlns="urn:jboss:domain:logging:2.0">

                                      <console-handler name="CONSOLE">

                                          <level name="INFO"/>

                                          <formatter>

                                              <named-formatter name="COLOR-PATTERN"/>

                                          </formatter>

                                      </console-handler>

                                      <periodic-rotating-file-handler name="FILE" autoflush="true">

                                          <formatter>

                                              <named-formatter name="PATTERN"/>

                                          </formatter>

                                          <file relative-to="jboss.server.log.dir" path="server.log"/>

                                          <suffix value=".yyyy-MM-dd"/>

                                          <append value="true"/>

                                      </periodic-rotating-file-handler>

                                      <size-rotating-file-handler name="PLATFORM" autoflush="true">

                                          <level name="DEBUG"/>

                                          <file relative-to="jboss.server.log.dir" path="PLATFORM.log"/>

                                          <append value="true"/>

                                      </size-rotating-file-handler>

                                      <logger category="com.dell.dsm">

                                          <level name="DEBUG"/>

                                          <handlers>

                                              <handler name="PLATFORM"/>

                                          </handlers>

                                      </logger>

                                      <logger category="org.apache.http" use-parent-handlers="false">

                                          <level name="DEBUG"/>

                                          <handlers>

                                              <handler name="PLATFORM"/>

                                          </handlers>

                                      </logger>

                                      <root-logger>

                                          <level name="DEBUG"/>

                                          <handlers>

                                              <handler name="CONSOLE"/>

                                              <handler name="FILE"/>

                                          </handlers>

                                      </root-logger>

                                      <formatter name="PATTERN">

                                          <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>

                                      </formatter>

                                      <formatter name="COLOR-PATTERN">

                                          <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>

                                      </formatter>

                                      <logging-profiles>

                                          <logging-profile name="sample">

                                              <size-rotating-file-handler name="SIZE" autoflush="true">

                                                  <level name="DEBUG"/>

                                                  <file relative-to="jboss.server.log.dir" path="samplePRF.log"/>

                                                  <append value="true"/>

                                              </size-rotating-file-handler>

                                              <logger category="com.dell.dsm.sample" use-parent-handlers="false">

                                                  <level name="DEBUG"/>

                                                  <handlers>

                                                      <handler name="SIZE"/>

                                                  </handlers>

                                              </logger>

                                          </logging-profile>

                                     </logging-profiles>

                                </subsystem>

                           

                          Thanks again for helping me understand how things work (or don't work).

                           

                          Regards,

                           

                          -Cheryl