-
1. Re: How to get logging fix for [LOGMGR-111] into WildFly 8.2.1?
nickarls May 31, 2016 4:14 AM (in response to cmrozien)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 May 31, 2016 12:03 PM (in response to nickarls)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 Jun 6, 2016 3:46 PM (in response to 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 Jun 6, 2016 3:53 PM (in response to cmrozien)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 Jun 6, 2016 5:12 PM (in response to nickarls)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 Jun 10, 2016 2:36 PM (in response to cmrozien)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 Jun 10, 2016 4:01 PM (in response to jamezp)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 Jun 10, 2016 4:23 PM (in response to 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.
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 Jun 10, 2016 5:45 PM (in response to 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.
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