Our Java WebStart application does not include a log4j configuration file; it simply sets up some hardcoded loggers and appenders.
I would like individual clients to be able to drop a log4j.properties file in somewhere and set up their own custom logging in troubleshooting situations. I could bundle a log4j.properties file into one of the jars of our application somewhere and that would allow configuration, but then the configuration would be the same for each client instead of only affecting the client that I want to troubleshoot. Plus, I wouldn't be able to change settings on the fly.
Is there a way I can hijack the log4j initialization procedure to use a per-client configuration file?
The basic problem here, is that Java Web Start severely restricts the access to the machine.
You should be able to do this, if you are running a signed application AND the user allows you full access to the machine. If not, you cannot do this with log4j with the default mechanism.
You may want to write your own configurator which reads from the file system using the Java WebStart API an then feeds that to log4j, but it will require some elbow grease.
You could use the PersistenceService to store the log4j configuration on the local user's machine (works without signing), or at least store a flag on whether to load a special config or not at startup of your web start application.
There is also a FileOpenService with which the end-user could open a local log4j.xml file to re-configure the logging facility on the fly. That way, the user has the control over the configuration and he has the control when and where to apply it.
Your app code which uses the FileOpenService to get the stream to the log4j configuration file can then use the DOMConfigurator.configure(InputStream) to reconfigure log4j.
Related
I'm running a web application in a Weblogic server (Im not realy familiar with ).
Via JVM args a log4j config is passed with log level DEBUG to the application.
In the log file I can also find some log entries of DEBUG level.
So far so good.
During debugging I found some calls to logger.debug() that are not in the log file.
private static final org.slf4j.Logger logger = LoggerFactory.getLogger(ActionCtr.class);
The method call is definitely hit but nothing is written to a file.
If I do a step into during debugging I see in the logger:
org.slf4j.impl.JDK14LoggerAdapter(com.example.application.ActionCtr)
"java.util.logging.FileHandler.pattern" -> "%h/java%u.log"
And this leads to some questions for me (as I can not change the running application):
1) how could it bee that it uses the application is using a mixed up log4j and java.util.logging
2) How could I determine what is used in what classes?
3) There is no %h/java%u.log (~/java*.log) so I've tried to provide a java.util.logging conform properties file,
but this changed nothing - how an I determine where the running logger got its config from to configure it right?
1) how could it be that it uses the application is using a mixed up log4j and java.util.logging
Any of those logging frameworks could be used by the application directly or a dependent library that the application is using. It doesn't take too many dependencies to end up with a bunch of logging framework hitchhikers.
The SLF4J manual explains how that logging framework wrangles all of these other frameworks. This why you are seeing the org.slf4j.impl.JDK14LoggerAdapter.
How could I determine what is used in what classes?
Assuming you mean direct usages you can use Jdeps or Javap.
how an I determine where the running logger got its config from to configure it right?
The JConsole tool can access the JUL loggers at runtime. It will also show you all of the system properties which may include paths to logging.properties files.
If the application is pragmatically configuring the logging in an non-standard way then one option would be to use the java.security.debug using the access option. Run the application under a security manager will all or all required permissions but then enable access tracing.
I have a Maven java project, my logging.properties is placed under resources folder. I have configured to print FINE level messages using console logger.
The WAR file generated has the properties file under WEB-INF/classes but, the application when deployed and executed, I can see only INFO level logs.
Should i initialize any LogConfiguration apart from having my logging.properties in the correct path ?
As describe here, you configure loggers in Liberty by something like this in the server.xml:
<logging traceSpecification="*=audit:com.myco.mypackage.*=debug"/>
and see the logging metatype doc to configure other aspects like log file size, number of logs to keep, etc.
Or, as the article mentions, you can use the bootstrap.properties
entries to do the same, e.g. com.ibm.ws.logging.trace.specification.
Though WebSphere also supports java.util.logging APIs, its full infrastructure isn't necessarily configured the same way as say Tomcat, which your app may be patterned after.
If you want to configure different logging behavior for different applications you can have the application Java code use a different Logger name for each, and then configure them differently through the single server.xml config (or also potentially separate the apps out onto different servers).
Dynamically changing the trace settings on a running server can be done simply by editing the server.xml config (as can dynamically configuring almost any aspect of Liberty).
Our Spring Boot application uses log4j2 for logging, but the admins of the server we are going to deploy it to require that:
the logging be fully configurable on their end, i.e., there must be a log4j2.xml file that they can edit to adjust logging formats, files, levels etc., and
The configuration must not be lost or overridden when a new version of the app is deployed (the upload war -> stop tomcat -> delete webapp folder -> start Tomcat) process will be automated.
Ideally, the path to log4j2.xml should be set in the webapps context .xml file — since that's where the DB connection config is. But I can't seem to find a way to make this work. All search results talk about using META-INF/web.xml or application.properties files (not an option, since they get overwritten on deploy), and the only SO question I could find (Spring application without web.xml log4j configuration) did not work for me ("No Configuration was provided") exception on startup.
Set the environment variable logging.config to be the location of your log4j2.xml file.
It's also recommended that you call it log4j2-spring.xml
See https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-logging.html
section "Custom log configuration"
I'm trying to essentially configure logging in three places, independently. Ideally, each component that is logging is fully unaware of the others. I'd like to use logback for this, as it seems to have some decent features and performance.
Here are the places from which I would like to log from and to:
Tomcat (7) should log to ${catalina_home}/logs/catalina.out, and should only log Tomcat events (deployments, server startup, etc)
A web application hosted in Tomcat should log to ${catalina_home}/logs/application.log, and should only log application things, like results of request validations or errors
A library that is included in the web application should log to ${catalina_home}/logs/library.log, and should only log things specific to that library, like time it takes to interact with some other web-service or library-specific errors
I know this is probably not the way it would work, but I would think I need to have a logback.xml file for each concern. Actually, I have created them and added to the classpath such that I get a "logback.xml occurs multiple times on the classpath" error.
I can see why I would need to consolidat my application and my library logback configuration to a single logback.xml file, but how would I keep the container logging config separate from the application+library logging config? Adding a logback config file to my application, as well as logback enabling Tomcat as described here, still yields a "multiple logback.xml" error. And, Chapter 9 of the logback user manual, which talks about separation of logging, doesn't really show how to separate the container and applications (just multiple applications), unless I am missing something there.
I have a web application consisting of severals modules. All the modules are packaged together in one single ear.
One of them is a brand new groovy app, while others are more old school. This new grails app is not under my responsibility.
Notice that grails is not using any log4j.[properties|xml] file, but it as its own DSL which interact directly with log4j at runtime. This configuration is located inside a config.groovy script, packaged with the application.
Log4j is configured using an external file and the -Dlog4j.configuration option for the JVM.
The problem is the grail configuration is containing a very liberal config:
- set the root level to info
- add a console appender
The result is that the external configuration is hijacked by grails:
now there are two console appender (logging twice the same info) and lots of useless info data are logged.
Is there another solution than a programmatic approach, to tell grails to stop being rude ?
You could just turn off the grails logging so it uses the external logger
http://blog.saddey.net/2010/02/07/grails-how-to-use-native-server-logging-configuration-eg-tomcat-glassfish-jboss/